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

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Fri Sep 4 08:10:41 EDT 2009


> Better yet, perhaps we invent some sort of 'resolvable identifier' that includes an attribute which is the URL for a resolver?
 
I think this would defeat the purpose of using urn.  urn was suppose to point to a resource without any explicit reference to its location.  Doing so would be essentially be equivalent to 
 
xlink:href="http://some.location.org/.../.../#urn:cgi:classifier:CGI:Lithology:200811:andesitic_rock <http://some.location.org/.../.../#some-id> "
 
(would it ?) 
 
>note that the codespace here is "urn:ietf:rfc:2141", because the identifier is a URN.  The classifierScheme is "urn:cgi:classifierScheme:CGI:Lithology:200811", which can be derived from the URN.  This sort of scheme would require that the data consumer knows the correct requests to make to the service to get a term definition or language localization, which would be greatly facilitated if there was some standard vocabulary service specification...
 
I added a suggestion to https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/ServiceArchitectureTG that I wish to present. It delegates the URN resolution to a WPS (Web Processing Service).  I hope to have a prototype ready for GIN (wet GIN).  In a nutshell, the instance document is sent to a urn resolution service that is specific to a domain (GIN, OneGeology, etc..) and each reference to a urn is resolved.  The WPS would return a collection of gsml:ControlledConcept (or SKOS items ?).  I want to avoid have a client hitting a resolver for each urn individually, I suspect that a typical document will have many duplicate reference to the same concept.
 
Eric
 
 
 

________________________________

De : Stephen M Richard [mailto:steve.richard at azgs.az.gov] 
Envoyé : 3 septembre 2009 15:36
À : Boisvert, Eric
Cc : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] RE : CGI Value abomination [SEC=UNCLASSIFIED]


The xlink:href to controlled concepts only works for elements that take a ControlledConcept as a value (and allow byReference); scopedName is the link to controlledConcept when the element takes CGI_TermValue, which has a value, which is a ScopedName, which we want to point at a controlledConcept. 

The URI for the concept is unique, and the CGI identifier scheme actually includes the classifierScheme in the URN, so including the classifierScheme as the codespace for the concept is indeed redundant. If the classifierScheme URI were easier to resolve it would be a convenience. Better yet, perhaps we invent some sort of 'resolvable identifier' that includes an attribute which is the URL for a resolver?

<Identifier resolver="http://srvgeosciml.brgm.fr/exist/brgm_geosciml/concept.xql" <http://srvgeosciml.brgm.fr/exist/brgm_geosciml/concept.xql>  codespace="urn:ietf:rfc:2141">urn:cgi:classifier:CGI:Lithology:200811:andesitic_rock</Identifier>

note that the codespace here is "urn:ietf:rfc:2141", because the identifier is a URN.  The classifierScheme is "urn:cgi:classifierScheme:CGI:Lithology:200811", which can be derived from the URN.  This sort of scheme would require that the data consumer knows the correct requests to make to the service to get a term definition or language localization, which would be greatly facilitated if there was some standard vocabulary service specification...

steve


Boisvert, Eric wrote: 

	Can't someone remind me why we have apparently 2 ways to refered to ControlledConcept ?
	The xlink:href and the ScopesName.  I vaguely remember that if a scopeName contains certains urn, the value must contains a urn.
	
	
	  

		in that case is the URI for the concept, the codespace is the URI for the containing vocabulary
		    

	
	Aren't urn unique anyway ?.  Isn't the first urn redundant (or it's just a 'trigger' ?)
	
	Eric
	
	
	-----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 Stephen M Richard
	Envoyé : 3 septembre 2009 14:34
	À : Simon Cox
	Cc : auscope-geosciml at lists.arcs.org.au
	Objet : Re: [Auscope-geosciml] RE : CGI Value abomination [SEC=UNCLASSIFIED]
	
	ScopedName is intended to account for controlled concepts, but we need to make it clear that the 'name' in that case is the URI for the concept, the codespace is the URI for the containing vocabulary (or do we pick a different convention?), and establish an operational way to resolve these URI's. These are application profile and architecture issues.
	steve
	
	Simon Cox wrote:
	  

		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 
		
		
		  
		    

	
	  


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


More information about the GeoSciML mailing list