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

Simon Cox simon.cox at jrc.ec.europa.eu
Fri Sep 4 12:18:19 EDT 2009


DNS only solves the first part of the problem - getting to the host. 
Then that host has to know what to serve. 
== resolver
 

--------------------------------------------------------
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: Friday, 4 September 2009 17:20
To: Boisvert, Eric
Cc: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] RE : CGI Value abomination
[SEC=UNCLASSIFIED]


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/.../.../#some-id>
http://some.location.org/.../.../#urn:cgi:classifier:CGI:Lithology:200811:an
desitic_rock"
 
(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:andesi
tic_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/3790461c/attachment.htm>


More information about the GeoSciML mailing list