[Auscope-geosciml] RE : RE : CGI Value abomination [SEC=UNCLASSIFIED]

Laxton, John L jll at bgs.ac.uk
Fri Sep 4 05:09:51 EDT 2009


I think once we start having specific placeholders for codes things are going to get complicated quite quickly. For example we have two codes, one used as a primary key in the StratigraphicLexicon and the other for map symbolisation. I guess other folk may use different codes for different things. As all these codes are generally referenceable through the StratigraphicLexicon (as in the example below) wouldn't it be best to simply use the Stratigraphic Name as the only name for GeologicUnit and anyone who wants the various codes can go to the StratigraphicLexicon to get them?

John

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: 04 September 2009 00:35
To: auscope-geosciml at lists.arcs.org.au
Cc: Alexandre.Robin at spotimage.fr
Subject: Re: [Auscope-geosciml] RE : RE : CGI Value abomination [SEC=UNCLASSIFIED]


So... as I understand it, I can't write a WFS filter to specifically query, for instance, Map_symbol or GeologicalUnitName in the instances below....

<gsml:GeologicUnit gml:id="GA_GeologicUnit_Stratno_134">
<gml:name codeSpace="urn:cgi:classifierScheme:GA:StratigraphicLexicon:Stratname">Adelong Norite</gml:name>
<gml:name codeSpace="urn:cgi:classifierScheme:GA:StratigraphicLexicon:Map_symbol">Sgad</gml:name>

<gsml:GeologicUnit gml:id="gu.26931319">
<gml:name codeSpace="urn:cgi:classifierScheme:GSV:GeologicalUnitName">Bacchus Marsh Formation</gml:name>
<gml:name codeSpace="urn:cgi:classifierScheme:GSV:GeologicalUnitCode">Pxb</gml:name>

Does the community see a need for a more GeoSciML-specific encoding of the geological unit name and map_symbol/unit_code/map_code, as opposed to the current use of the generic gml:name for both of these descriptors?

A suggestion might be that gml:name be reserved strictly for the name of the unit (eg: Adelong Norite, Bacchus Marsh Formation), and we create a specific GeoSciML placeholder for map_symbol/unit_code/map_code?

Any thoughts?

------------------------------------------------------------------------------------------------
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: Thursday, 3 September 2009 7:51 PM
To: auscope-geosciml at lists.arcs.org.au; auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov
Cc: Robin, Alexandre
Subject: [Auscope-geosciml] RE : RE : CGI Value abomination [SEC=UNCLASSIFIED]

Actually, you can't, or at least not to the point that codeSpace is of any use.  Filter sees the world in denormalised form.

consider this instance

<Feature>
  <gml:name codeSpace="urn:1">concept_a</gml:name>
  <gml:name codeSpace="urn:2">concept_b</gml:name>
</Feature>

We want to select concept_a of codeSpace urn:2 (this instance should not match)

<ogc:And>
   <ogc:PropertyIsEqualTo>
     <ogc:PropertyName>gml:name</ogc:PropertyName>
     <ogc:Literal>concept_a</ogc:Literal>
   </ogc:PropertyIsEqualTo>
   <ogc:PropertyIsEqualTo>
     <ogc:PropertyName>gml:name/@codeSpace</ogc:PropertyName>
     <ogc:Literal>urn:2</ogc:Literal>
   </ogc:PropertyIsEqualTo>
</ogc:And>

will match the instance

This problem has been reported some times ago.

This means that we can't really target specific codeSpace when we query a term, codeSpace are useless in filter.
I know it is unlikely that many codeSpace for the same property are to be present in the same feature (gml:name is the only one I can think of), but just to point out that codeSpace can't be use to tell term apart in WFS/Filter.  You might as well ignore codeSpace filtering altogether. and hope that the term is unique.

I don't think it's a show stopper, it will return false positive in the worst case scenario.

Eric





________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon Cox
Date: jeu. 2009-09-03 05:31
À: auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov
Cc: 'Robin, Alexandre'
Objet : Re: [Auscope-geosciml]RE : CGI Value abomination [SEC=UNCLASSIFIED]



Yes - I still strongly urge y'all to attempt a 'cull' of the soft-typed
values,
and replace them with ScopedName (this _is_ ControlledConcept Steve!) or
Measure wherever possible.
As Eric points out, you can actually write filters against those.


--------------------------------------------------------
Simon Cox

European Commission, Joint Research Centre,
Institute for Environment and Sustainability,
Spatial Data Infrastructures Unit, TP 262
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox at jrc.ec.europa.eu
http://ies.jrc.ec.europa.eu/simon-cox

SDI Unit: http://sdi.jrc.ec.europa.eu/
IES Institute: http://ies.jrc.ec.europa.eu/
JRC: http://www.jrc.ec.europa.eu/
--------------------------------------------------------

-----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: Thursday, 3 September 2009 11:21
To: auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov;
auscope-geosciml at lists.arcs.org.au
Cc: Robin, Alexandre
Subject: [Auscope-geosciml] RE : CGI Value abomination [SEC=UNCLASSIFIED]

There still the WFS issue.

If one of the requirement is to be WFS (Filter) queriable, I don't think we
can go sweCommon. At least not with any softtyping solutions.  This said,
there are already many GeoSciML reasonnable queries that we can't do in
ogc:Filter.
Eric

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon Cox
Date: jeu. 2009-09-03 04:43
À: steve.richard at azgs.az.gov; auscope-geosciml at lists.arcs.org.au
Cc: 'Robin, Alexandre'
Objet : Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]


Steve, Eric, John -

I think you have a strong understanding of the requirements.
Can I suggest you engage with Alex Robin directly.
I'm sure he would be very pleased to assist, if it led to the adoption of
sweCommon in GeoSciML.
Right Alex?

Simon


--------------------------------------------------------
Simon Cox

European Commission, Joint Research Centre Institute for Environment and
Sustainability Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749,
I-21027 Ispra (VA), Italy
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox at jrc.ec.europa.eu <mailto:simon.cox at jrc.ec.europa.eu>
http://ies.jrc.ec.europa.eu/simon-cox
<http://ies.jrc.ec.europa.eu/simon-cox>

SDI Unit: http://sdi.jrc.ec.europa.eu/ <http://sdi.jrc.ec.europa.eu/> IES
Institute: http://ies.jrc.ec.europa.eu/ <http://ies.jrc.ec.europa.eu/>
JRC: http://www.jrc.ec.europa.eu/ <http://www.jrc.ec.europa.eu/>

--------------------------------------------------------




________________________________

        From: auscope-geosciml-bounces at lists.arcs.org.au
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Stephen M
Richard
        Sent: Wednesday, 2 September 2009 21:10
        To: auscope-geosciml at lists.arcs.org.au
        Subject: Re: [Auscope-geosciml] CGI Value abomination
[SEC=UNCLASSIFIED]


        The swe abstract data components all have a Quality property, which
is a union that includes a categoryQuality and textQuality. Can the kind of
qualifiers we're using (always, common, never, sometimes, rare, equalTo,
greaterThan, lessThan, approximate, quadratic mean, ...mode, median) be
accounted for using categoryQuality? CategoryQuality appears in the sensorML
v.1.0 uml in HollowWorld, but a search of the pdf for SensorML (OGC 07-000)
gets no hits on categoryQuality, so there's not any discussion of the
intention of the quality category.

        can swe:singleConstraint account for greaterThan, lessThan type
bounding value declarations?
        the quadratic mean, harmonic mean, geometric mean, arithmetic mean,
mode, median have to do with the observation procedure, but how does swe
attach those to data?  Using abstractDataComponent.definition URI?
        always, common, sometimes seem like possible quality categories.
        'Never' is only necessary for defining descriptions where the
presence of some property precludes membership in a category -- I don't
think it would appear in any kind of occurrence description. This kind of
information should be encoded with OWL or something like that anyway, so
maybe we can deprecate it.

        So maybe don't need to change swe?

        BUT...
        SWE does not appear to have a CategoryRange that would account for
CGI_TermRange.
        We still have the case brought up by Bruce or Ollie of geophysical
data for which there is a value range and a typical or preferred value

        Maybe these could be accounted for with some elements derived from
swe:dataArray?

        steve


        Simon Cox wrote:

                But if it is a common requirement, there should be a common
slot for it,
                rather than making it part of the tuple definition.
                The latter is pretty much back to free-text.


                --------------------------------------------------------
                Simon Cox

                European Commission, Joint Research Centre,
                Institute for Environment and Sustainability,
                Spatial Data Infrastructures Unit, TP 262
                Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
                Tel: +39 0332 78 3652
                Fax: +39 0332 78 6325
                mailto:simon.cox at jrc.ec.europa.eu
                http://ies.jrc.ec.europa.eu/simon-cox

                SDI Unit: http://sdi.jrc.ec.europa.eu/
                IES Institute: http://ies.jrc.ec.europa.eu/
                JRC: http://www.jrc.ec.europa.eu/
                --------------------------------------------------------

                -----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: Wednesday, 2 September 2009 19:22
                To: auscope-geosciml at lists.arcs.org.au
                Subject: Re: [Auscope-geosciml] CGI Value abomination
[SEC=UNCLASSIFIED]

                Can't the qualifier be modelled as a part of the complex
value

                Eg:

                <gsml:result>123 15 23.5 APPROX</gsml:result>

                Just a thought


                -----Message d'origine-----
                De : auscope-geosciml-bounces at lists.arcs.org.au
                [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la
part de Simon Cox
                Envoyé : 2 septembre 2009 12:26 À :
auscope-geosciml at lists.arcs.org.au
                Objet : Re: [Auscope-geosciml] CGI Value abomination
[SEC=UNCLASSIFIED]

                I was responding to John's mail, where he appeared to be
saying 'some fields
                will never be interoperable' (because of institutional
reasons). If we
                really think they aren't (and he may have a point here),
then there is zero
                benefit and only cost in forcing a data provider to coerce
their
                non-ineroperable data into complex structures.

                Eric brought up SWE Common as a (more broadly accepted)
alternative, though
                he pointed out that in practice SWE Common is as permissive
as CGI_Value
                (but probably has more code to support it - though I think
it is only
                maintained by one person (Alex Robin) who does not keep his
documentation
                up-to-date).

                If there is interest in looking at SWE Common as a
replacement (I agree that
                it probably has more momentum, and Alex is very diligent in
publicizing it),
                but are concerned about the absence of _qualifiers_ (or
anything else in
                fact) then can I suggest that this requirement is URGENTLY
brought to the
                SWE Common v2.0 revision working group in OGC - they are
actively working on
                v2.0, and my guess is it will be wrapped up in a matter of
months.


                --------------------------------------------------------
                Simon Cox

                European Commission, Joint Research Centre, Institute for
Environment and
                Sustainability, Spatial Data Infrastructures Unit, TP 262
Via E. Fermi,
                2749, I-21027 Ispra (VA), Italy
                Tel: +39 0332 78 3652
                Fax: +39 0332 78 6325
                mailto:simon.cox at jrc.ec.europa.eu
                http://ies.jrc.ec.europa.eu/simon-cox

                SDI Unit: http://sdi.jrc.ec.europa.eu/
                IES Institute: http://ies.jrc.ec.europa.eu/
                JRC: http://www.jrc.ec.europa.eu/
                --------------------------------------------------------

                -----Original Message-----
                From: auscope-geosciml-bounces at lists.arcs.org.au
                [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On
Behalf Of Stephen M
                Richard
                Sent: Wednesday, 2 September 2009 18:15
                To: auscope-geosciml at lists.arcs.org.au
                Subject: Re: [Auscope-geosciml] CGI Value abomination
[SEC=UNCLASSIFIED]

                Simon--Interoperability is defined by some community of
practice. Sure, some
                group could agree to some free text format for data
interchange, but then
                they'd dispense with xml and OGC services entirely and pass
around
                tab-delimited text files.  We've been there, and know how
well or poorly
                that works.

                What is the problem with leaving the xml schema quite
general, allowing for
                different value quantification schemes, with the
understanding that
                communities wishing to share data using GeoSciML services
will have to
                develop an application profile restricting some of the
possibilities?
                The benefit of the model is in establishing patterns for how
this is done,
                so that each solution to the same problem is not different.

                To me the important question for Quebec is how much we can
do using SWE,
                since the value quantification issue is certainly not only a
geoscience
                problem! Maybe replace CGI_Value with some element
(swe:DataArray?) or
                elements from SWE. We need to analyze the places CGI_Value
is used in
                GeoSciML (see list below), and figure out if there is more
than one pattern,
                and decide if we need to change it.

                steve



                        CGI_Value is used for:
                        Bedding thickness
                        Event age
                        part proportion (GUPart, composition, rock
constituent part) several
                        geophyscial properties (magnetic susceptibility,
permeability,
                        porosity, CGI_PhysicalDescription) mapped feature
position accuracy
                        trend, plunge, azimuth and dip on orientation values
particle geometry
                        description properties (grain size, sorting, shape,
and aspect ratio)



                Simon Cox wrote:


                        In that case you can make everything that is not an
'interoperable'
                        field just free-text.
                        This would still say that CGI-Value could be
dispensed with.



--------------------------------------------------------
                        Simon Cox

                        European Commission, Joint Research Centre,
Institute for Environment
                        and Sustainability, Spatial Data Infrastructures
Unit, TP 262 Via E.
                        Fermi, 2749, I-21027 Ispra (VA), Italy
                        Tel: +39 0332 78 3652
                        Fax: +39 0332 78 6325
                        mailto:simon.cox at jrc.ec.europa.eu
                        http://ies.jrc.ec.europa.eu/simon-cox

                        SDI Unit: http://sdi.jrc.ec.europa.eu/ IES
Institute:
                        http://ies.jrc.ec.europa.eu/
                        JRC: http://www.jrc.ec.europa.eu/

--------------------------------------------------------

                        -----Original Message-----
                        From: auscope-geosciml-bounces at lists.arcs.org.au
                        [mailto:auscope-geosciml-bounces at lists.arcs.org.au]
On Behalf Of
                        Laxton, John L
                        Sent: Wednesday, 2 September 2009 11:39
                        To: auscope-geosciml at lists.arcs.org.au
                        Subject: Re: [Auscope-geosciml] CGI Value
abomination
                        [SEC=UNCLASSIFIED]

                        The snag with limiting users to the number of
formats they can use is
                        that the chosen format may not match the user's
database. We recently
                        hit this with unitThickness defined as CGI_Numeric.
Fair enough you
                        might think but in our database unit thickness is a
string with
                        comments like 'c23m in Grantham area'. The
unfortunate reality is that
                        in lots of cases different data providers hold the
same property in
                        different formats. We could remodel them as distinct
properties for
                        different formats (Ollie's option (b)) but this is
only going to be
                        worthwhile where we wish to query against the
property. In most cases
                        all we wish to do is deliver a property value and
I'm not convinced it
                        matters if the way BGS delivers something like
                        ParticleGeometryDescription.sorting is different
from the way AZGS
                        does - we need to be realistic about the level of
interoperability
                        needed. Particular services can always specify more
restrictive


                requirements if needed as OneGeology-Europe is doing.


                        John

                        -----Original Message-----
                        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: 02 September 2009 05:49
                        To: Rob.Atkinson at csiro.au;
auscope-geosciml at lists.arcs.org.au
                        Subject: Re: [Auscope-geosciml] CGI Value
abomination
                        [SEC=UNCLASSIFIED]

                        I agree with Simon's sentiments.  But Rob's comments
have me confused.
                        I can't see how making CGI_Value a specialisation of
another class is
                        going to make the model more interoperable.  It
still leaves users
                        able to deliver some attribute values as either term
values, number
                        values


                or ranges.


                        The aim here is to:

                        a) limit users in the number of formats they can use
to deliver
                        attribute values, and

                        b) redefine some model elements (eg: Age) so that
they explicitly
                        state, for example, "this attribute is for a
numerical Age only" or
                        "this attribute is for a term Age only", rather than
the existing
                        "this attribute can be a numeric Age, or a term Age,
or a range of
                        numeric


                and term Ages".


                        Cheers,
                        Ollie




                ...clipped...

                --
                Stephen M. Richard
                Section Chief, Geoinformatics
                Arizona Geological Survey
                416 W. Congress St., #100
                Tucson, Arizona, 85701 USA

                Phone:
                Office: (520) 209-4127
                Reception: (520) 770-3500
                FAX: (520) 770-3505

                email: steve.richard at azgs.az.gov

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




        --
        Stephen M. Richard
        Section Chief, Geoinformatics
        Arizona Geological Survey
        416 W. Congress St., #100
        Tucson, Arizona, 85701 USA

        Phone:
        Office: (520) 209-4127
        Reception: (520) 770-3500
        FAX: (520) 770-3505

        email: steve.richard at azgs.az.gov

_______________________________________________
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


_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml


-- 
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/20090904/18cb1eed/attachment.htm>


More information about the GeoSciML mailing list