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

Stephen M Richard steve.richard at azgs.az.gov
Fri Sep 4 11:19:41 EDT 2009


Yes, including a 'resolver' url would be functionally equivalent to the 
xlink you show (as far as I can tell). I guess the question in the back 
of my mind is why not use http protocol for identifiers, since there's 
already a very efficient resolution service out there (DNS). This is one 
aspect of URN's that's always bothered me. I know http is not meant as 
an identifier scheme, but that's what it is in fact.

If we do have to build our own name resolution infrastructure, I like 
your WPS suggestion.

steve

Boisvert, Eric wrote:
> > 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" 
> 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

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


More information about the GeoSciML mailing list