[Auscope-geosciml] RE : RE : CGI Value abomination [SEC=UNCLASSIFIED]
Oliver.Raymond at ga.gov.au
Oliver.Raymond at ga.gov.au
Thu Sep 3 19:35:16 EDT 2009
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<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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20090904/c3a043a2/attachment.htm>
More information about the GeoSciML
mailing list