[auscope-geosciml] CGI_Term and qualifier [SEC=UNCLASSIFIED]

Stephen M Richard steve.richard at azgs.az.gov
Thu Aug 12 10:48:39 EDT 2010


  Eric--you address the two kinds of qualifiers we represented in the 
NGMDB database design (AttributeRelationship)--uncertainty in the value 
assignment, and actual variability in the thing described.  The existing 
qualifier vocabulary 
(http://ngwd-bdnes.cits.nrcan.gc.ca/service/resolver/resolve/classifierScheme/CGI/ValueQualifier/200811.html  
-- thanks Eric B.!) includes the variability terms, but not the 
uncertainty terms.
steve

On 8/11/2010 4:46 AM, Boisvert, Eric wrote:
> is there any provision for uncertainty about term assignement or when 
> multiple assignements are possible (either/or) or is this something 
> for the observation model (btw, <<estimatedProperty>> stereotype is 
> still not implemented in the schema, while used profusely in the model 
> - I think it's an issue we are hauling since Tucson !).  Some term are 
> 0..* but in this case is does not mean uncertainty, but real 
> multiplicity, ie "there are yellow and red instances" vs "unsure if 
> it's yellow or red".
>
> ------------------------------------------------------------------------
> *De :* auscope-geosciml-bounces at lists.arcs.org.au 
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] *De la part de* 
> Oliver.Raymond at ga.gov.au
> *Envoyé :* 11 août 2010 00:58
> *À :* auscope-geosciml at lists.arcs.org.au
> *Objet :* [auscope-geosciml] CGI_Term and qualifier [SEC=UNCLASSIFIED]
>
> Hi Bruce,
>
> I think we are all of one mind now with the use of xlink:href and 
> xlink:title for controlled vocabularies.  I have heard no dissent.
>
> The use of CGI_Term:value everywhere would simplify the model, in that 
> we would not have to support the many specific codelist stubs 
> currently in the model.  Simon's argument for the specific byReference 
> codelists (instead of a generic value codelist) was to introduce a 
> greater degree of explicitness (is that a word?) into the model where 
> qualifier is not appropriate.  Both methods can deliver the same 
> controlled vocabularies via xlink:href, but Simon's method doesn't 
> permit the use of a qualifier for the more specific codelists.
>
> On logic grounds, I am not supportive of a qualifier (optional or 
> otherwise) being associated with attributes such as faultType, 
> contactType, geologicUnitType, instrumentType, etc.
>
> A problem I see with qualifier being optional is one of 
> interoperability (how is a client going to know when to expect 
> delivery of a qualifier?).  Perhaps a mandatory, but nillable, qualifier?
>
> I also notice that the 'qualifier' in CGI_Term is currently 
> byReference in v3RC1 schemas, which means that we need to turn the 
> ValueQualifierCode enumeration into a rdf vocabulary (Steve?) that can 
> be accessed by href.
>
> Cheers,
>
> Ollie
>
> /------------------------------------------------------------------------------------
> //Ollie Raymond//
>
> *National Advice, Maps and Data Standards Project
> *Geoscience Australia
>
> *GeoSciML Design Group
> *IUGS Commission for the Management and Application of Geoscience 
> Information/
>
> /------------------------------------------------------------------------------------
> /
> *Address:* GPO Box 378, Canberra, ACT, 2601, Australia *|* *ABN:* 80 
> 091 799 039
> *Ph:* +61 2 62499575 *|* *Fax:* +61 2 62499992 *|* *Email: 
> *Oliver.Raymond at ga.gov.au <mailto:Oliver.Raymond at ga.gov.au> *|* 
> *_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>_ 
>
> *National geological maps 
> _http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp_
> Geoscience Australia web services 
> _http://www.ga.gov.au/resources/applications/ogc-wms.jsp
> _/------------------------------------------------------------------------------------
> /
>  --- This message was created with 100% recycled electrons ---
>
> ------------------------------------------------------------------------
>
> *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:* Wednesday, 11 August 2010 1:14 PM
> *To:* auscope-geosciml at lists.arcs.org.au
> *Subject:* Re: [auscope-geosciml] problem with RockMaterial and 
> FabricDescription
>
>
> >Effectively CGI_Term is a qualifier/reference pair?
> I fully support this.
> We could use  CGI_Term everywhere, with the qualifier being optional.
> The value (reference) shoulf be byReference only, with the URI in the 
> xlink:href and the value in the xlink:title.  This provides a 
> consistent way of delivering content, whether coming from a controlled 
> vocabulary or not.
>
> Cheers
> Bruce
>
> Ph: +61-3-9658 4502
> Fax: +61-3-9658 4555
> Mobile: +61 429 177155
>
> *Alistair Ritchie <alistair.bh.ritchie at gmail.com>*
> Sent by: auscope-geosciml-bounces at lists.arcs.org.au
>
> 09/08/2010 04:08 PM
>
> Please respond to
> auscope-geosciml at lists.arcs.org.au
>
> 	
>
> To
>
> 	
>
> auscope-geosciml <auscope-geosciml at lists.arcs.org.au>
>
> cc
>
> 	
>
> Subject
>
> 	
>
> Re: [auscope-geosciml] problem with RockMaterial and       
>  FabricDescription
>
> 	
>
>
>
>
> Is there still a case, even then, for the CGI_Term.value (apologies if 
> I've got the model wrong) to be a reference? Effectively CGI_Term is a 
> qualifier/reference pair?
>
> Alistair Ritchie
> GEOSCIENCE VICTORIA | EARTH RESOURCES DIVISION
> Department of Primary Industries | Melbourne, Victoria, Australia
> Tel: +61 3 9658 4512 | Fax: +61 3 9658 4555
>
>
> On 9 August 2010 16:05, Stephen M Richard <steve.richard at azgs.az.gov 
> <mailto:steve.richard at azgs.az.gov>> wrote:
>  Gilly--the issue is that for some term value assignments, we commonly 
> qualify things-- mostly well consolidated, usually red... So for value 
> assignments that may be qualified, we have to use CGI term, because 
> the 'value' of the controlled concept (the term.value, which is 
> byReference) is modified by the qualifier (also byReference).
>
> We need to troll through the model again carefully to make sure the 
> use of CGI_Term is limited to those properties where qualfiers make 
> sense.  I just noticed GeologicFeature.observationMethod is a 
> CGI_Term..., not sure that makes sense.
>
> steve
>
>
> On 8/8/2010 10:24 PM, Guillaume.Duclaux at csiro.au wrote:
> Steve,
>
> I agree with you and IMHO all codeLists and CGI_Terms should be 
> byReference and point to a controlled vocab.
>
> Cheers
>
> Gilly
> On 09/08/2010, at 1:19 PM, Stephen M Richard wrote:
>
>  What is the logic for use of CGI_Term as the type for
> RockMaterial.lithology or for FabricDescription.fabricType.  In both
> cases the property is asserting a categorization of the described thing,
> and I can't think of how a value qualifer fits. Did I miss some
> discussion of this somewhere along the line?
>
> I suggest that these should be byReference (hrefs to controlled
> Vocabulary concepts), analogous to GeologicUnit.geologicUnitType,
> MaterialRelation.materialRelationshipType, or
> ParticleGeometryDescription.particleType.
>
> steve
>
> -- 
> Stephen M. Richard
> Arizona Geological Survey
> 416 W. Congress St., #100
> Tucson, Arizona, 85701
> USA
> phone: (520) 770-3500.  FAX: (520) 770-3505
> email: steve.richard at azgs.az.gov <mailto:steve.richard at azgs.az.gov>
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>
>
> -- 
> Stephen M. Richard
> Arizona Geological Survey
> 416 W. Congress St., #100
> Tucson, Arizona, 85701
> USA
> phone: (520) 770-3500.  FAX: (520) 770-3505
> email: steve.richard at azgs.az.gov <mailto:steve.richard at azgs.az.gov>
>
> _______________________________________________
> 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
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
> Notice:
> This email and any attachments may contain information that is 
> personal, confidential,
> legally privileged and/or copyright. No part of it should be 
> reproduced, adapted or communicated without the prior written consent 
> of the copyright owner.
>
> It is the responsibility of the recipient to check for and remove viruses.
>
> If you have received this email in error, please notify the sender by 
> return email, delete it from your system and destroy any copies. You 
> are not authorised to use, communicate or rely on the information 
> contained in this email.
>
> Please consider the environment before printing this email.
>
>
> _______________________________________________
> 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
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701
USA
phone: (520) 770-3500.  FAX: (520) 770-3505
email: steve.richard at azgs.az.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100812/57e8b37e/attachment.htm>


More information about the GeoSciML mailing list