[Auscope-geosciml] TermValues

Stephen M Richard steve.richard at azgs.az.gov
Tue Sep 1 13:28:33 EDT 2009


The bigger problem for me is the term values. How are ScopedNames to be 
resolved to ControlledConcepts, should TermValues always be 
ControlledConcepts, how to 'round trip' data.

In most cases the scopedNames are coming from a vocabulary that contains 
ControlledConcepts (or something that could be represented as a 
controlled concept). The current encoding of scoped names for terms from 
GeologicVocabularies seems to present two options:
1) codespace is urn:ietf:rfc:2141 and the value is the concept URN
2) codespace is urn for the concept scheme, and value is one of the 
preferred names from the vocabulary.

Option 1 seems preferable because in 2, matching the supplied value to 
the concept in the conceptScheme is not guaranteed unique since the 
gsml:names are not required to be unique. On the other hand, problems 
arise if someone receives an opaque URN--the user would *have* to have a 
means to resolve the URN to get the meaning. There is still no way to 
know how to resolve URN's automatically, an until there is a DNS-like 
service for URN protocol to match that for http, this will remain a problem.

But maybe CGI_TermValues should all be ControlledConcepts? We rejected 
this because its a pretty heavy weight solution for a situation in which 
a data provider just has a table with a bunch of home-grown terminology 
that they want to stuff into the interchange docs as strings. Of course, 
what kind of 'interoperability' does that provide?

One of the use cases of interest to me is packaging map data for data 
delivery (not necessarily in a WFS). One common requirement/request for 
this kind of function is the ability to export data and re-import the 
interchange document with no data loss. No data loss may not be 
achievable, but this process is much more likely to be possible if the 
original terms from source documents can always be included in an 
interchange document. For features that have gml:name we use the 
gml:name with codespace like "AZGS:tableName:fieldName" to put in the 
original values for terms mapped to the standard vocabularies. This does 
not work for values that are datatypes--e.g. CGI_TermValue.ScopedName. 
Use of controlled concepts for termValues would allow this by including 
the 'localVocabulary' as part of the package and using VocabRelations to 
record the mapping. This is another motivation to replace CGI_TermValue 
with controlledConcept. (these operations would also work if our 
GeologicVocabulary package is replaced by SKOS, which seems like a good 
idea to me).

Steve

Simon Cox wrote:
> Ollie, others:
>  
> I have been grumbling about this for a while, and hope that it can be 
> addressed in the upcoming meeting in Quebec.
>  
>  
> Way too many of the class attributes in GeoSciML use CGI_Value and its 
> variants.
>  
> I am fully aware of the history of when CGI_Value it was created 
> (Ottawa, 2005) and its value (it allowed us to move forward on the 
> bigger issues).
> It also allowed a lazy UML design process, where for most atttributes 
> the type was set following a logic of just 'we can't really think 
> about this now but it'll be some kind of word/number'.
>  
> Now I think it is time to set it aside and move on.
>  
> My fundamental objections to the almost ubiquitous use of CGI_Value are
> (i) it is hard to implement - it relies on XML Schema substitution groups
> (ii) it is not compatible with any other domain schema
> (iii) it allows data providers to be 'lazy' and create instances that 
> are not interoperable on arrival
> (iv) it forces decisions required for data-fusion over to the client - 
> this is fundamentally what a standard encoding is supposed to avoid!
> (v) it privileges a marginal GeoSciML use-case (transmission of field 
> data) at the expense of the dominant use-case (exchange of 
> quality-controlled archival data). 
>  
> Most of the time, the client will refer to 'standard definitions' 
> provided in the GeoSciML concept schemes to translate the values 
> provided into standard forms anyway, so why not get the provider to do 
> that rather than the client
>  
> It is the job of the GeoSciML design task group to actually make 
> some choices, fix the type of the basic class attributes, and then 
> require that service providers conform - make them make the choice 
> about the 'best' value for an attribute, don't shirk the job and push 
> it back to the client.
>  
> Almost all CGI_Value should be replaced by
> (a) ScopedName
> (b) Measure
> with just a few being
> (c) Range (new type)
>  
> 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
> 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/
>
> --------------------------------------------------------
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20090901/71fd0d42/attachment.htm>


More information about the GeoSciML mailing list