[GeoSciML] Correct encoding of swe:Category [SEC=UNOFFICIAL]

Laxton, John L. jll at bgs.ac.uk
Mon Apr 29 09:30:24 EDT 2013


Hi Ollie,

Did you ever get a reply to this?

John

From: geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org [mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org] On Behalf Of Oliver.Raymond at ga.gov.au
Sent: 19 March 2013 22:42
To: Alexandre.ROBIN at astrium.eads.net; mike.botts at botts-inc.net; david.w.case at nga.mil; simon.cox at csiro.au; michael.enoch at lmco.com; thomas.mccarty at dhs.gov; lmckee at opengeospatial.org; harryn at imagemattersllc.com; oreilly at mbari.org; resseguiedr at ornl.gov; rhynebt at ornl.gov; ingo.simonis at igsi.eu; tolliverjs at ornl.gov; Christopher.Tucker at gmail.com; a.wytzisk at conterra.de
Cc: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] Correct encoding of swe:Category [SEC=UNOFFICIAL]

Many thanks for your reply Alex.  A couple of extra questions...

1.  Not having a full URI for the "value" means that the client must know to concatenate "codespace" and "value" to be able to navigate to the linked resource for "value".  This is an extra imposition on clients that might be avoided by using the full URI in "value" for swe:Category not used in a block-encoded data stream.  Is there a problem for the SWE community if we (GeoSciML) use swe:Category in a way that maybe it was not originally intended (ie: not in a data stream) and use a full URI in "value"?

2. I might be presumptious of Simon's reply here (apologies in advance Simon), but my example of "codeSpace" and "value" URIs uses the URI scheme that the GeoSciML team (including Simon) develop - using "classifierscheme" for the vocabulary uri, and "classifier" for value URIs within a vocabulary.  We (the geoscience modelling and vocabulary community) would be very keen to know if your "good practice" of using the same URI root for both the vocabulary and the value is more widely used best practice.  It seems to me to be a fundamental thing to get standardised across all domains.

Cheers,
Ollie

________________________________
From: ROBIN, Alexandre [mailto:Alexandre.ROBIN at astrium.eads.net]
Sent: Wednesday, 20 March 2013 01:09
To: Raymond Oliver; mike.botts at botts-inc.net<mailto:mike.botts at botts-inc.net>; david.w.case at nga.mil<mailto:david.w.case at nga.mil>; simon.cox at csiro.au<mailto:simon.cox at csiro.au>; michael.enoch at lmco.com<mailto:michael.enoch at lmco.com>; thomas.mccarty at dhs.gov<mailto:thomas.mccarty at dhs.gov>; lmckee at opengeospatial.org<mailto:lmckee at opengeospatial.org>; harryn at imagemattersllc.com<mailto:harryn at imagemattersllc.com>; oreilly at mbari.org<mailto:oreilly at mbari.org>; resseguiedr at ornl.gov<mailto:resseguiedr at ornl.gov>; rhynebt at ornl.gov<mailto:rhynebt at ornl.gov>; ingo.simonis at igsi.eu<mailto:ingo.simonis at igsi.eu>; tolliverjs at ornl.gov<mailto:tolliverjs at ornl.gov>; Christopher.Tucker at gmail.com<mailto:Christopher.Tucker at gmail.com>; a.wytzisk at conterra.de<mailto:a.wytzisk at conterra.de>
Subject: RE: Correct encoding of swe:Category [SEC=UNOFFICIAL]
Hello Oliver,

Your example looks right. No need to use identifier since it is intended only to provide a unique identifier to global constants.
The only thing I would change is setup the codeSpace and content of the <swe:value> tag so that they can be concatenated to form the full URI without ambiguity.

I did just that in the example below : I added '/' at the end of the codespace URI and kept only the last part of the URL path in the <swe:values> tag.

<gsmlem:RockMaterial gml:id="BGS.rockmaterial.167775491107838873">  <!-- A GeoSciML rock material element -->
    <gsmlem:color>
        <swe:Category definition="http://resource.geosciml.org/classifier/cgi/2012/propertyTypes/color">  <!-- URI to a definition of the concept of color as applied to earth materials -->
            <swe:label>dark brown</swe:label>       <!-- a human-readable text label for the property value -->
            <swe:codeSpace xlink:href="http://resource.geosciml.org/classifierscheme/cgi/201201/color/" xlink:title="CGI color vocabulary - version 2012.01"/>  <!-- URI and human-readable label for the vocabulary of color values. -->
            <swe:value>dark_brown</swe:value>  <!-- URI to the unique identier for "dark brown" from the online vocabulary. -->
        </swe:Category>
    </gsmlem:color>
    <gsmlem:lithology xlink:href="http://resource.geosciml.org/classifier/cgi/simplelithology/sandstone" xlink:title="sandstone"/>
</gsmlem:RockMaterial>

This is not defined in the standard but is a good practice that, IMHO, we should try to follow. It is especially interesting in the case where we want to block encode multiple values of that property in a single data stream. In that case, we would want to include only the changing part in the data stream.

Others may have a different opinion on that though...
@Simon, do you know if what I suggested Oliver is also good GML practice?

Regards,

--------------------------------
Alexandre Robin
EADS - Astrium Satellites
System Engineer
AOCS/GNC Advanced Studies
Tel: +33 (0)5 62 19 76 01


________________________________
From: Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au> [mailto:Oliver.Raymond at ga.gov.au]
Sent: Tuesday, March 19, 2013 4:19 AM
To: mike.botts at botts-inc.net<mailto:mike.botts at botts-inc.net>; david.w.case at nga.mil<mailto:david.w.case at nga.mil>; simon.cox at csiro.au<mailto:simon.cox at csiro.au>; michael.enoch at lmco.com<mailto:michael.enoch at lmco.com>; thomas.mccarty at dhs.gov<mailto:thomas.mccarty at dhs.gov>; lmckee at opengeospatial.org<mailto:lmckee at opengeospatial.org>; harryn at imagemattersllc.com<mailto:harryn at imagemattersllc.com>; oreilly at mbari.org<mailto:oreilly at mbari.org>; resseguiedr at ornl.gov<mailto:resseguiedr at ornl.gov>; rhynebt at ornl.gov<mailto:rhynebt at ornl.gov>; ROBIN, Alexandre; ingo.simonis at igsi.eu<mailto:ingo.simonis at igsi.eu>; tolliverjs at ornl.gov<mailto:tolliverjs at ornl.gov>; Christopher.Tucker at gmail.com<mailto:Christopher.Tucker at gmail.com>; a.wytzisk at conterra.de<mailto:a.wytzisk at conterra.de>
Subject: Correct encoding of swe:Category [SEC=UNOFFICIAL]
Dear SWE DWG members,

The GeoSciML data standard (I am chair of the GeoSciML SWG) uses SWE Common elements.  We would like to get an official SWE DWG ruling on the correct way to encode data within a swe:Category element, because there is some confusion in our reading of the SWE spec documentation.

Our simple example is this: "This piece of sandstone is dark brown".  (Note that the urls are indicative only and won't resolve)

<gsmlem:RockMaterial gml:id="BGS.rockmaterial.167775491107838873">  <!-- A GeoSciML rock material element -->
    <gsmlem:color>
        <swe:Category definition="http://resource.geosciml.org/classifier/cgi/2012/propertyTypes/color">  <!-- URI to a definition of the concept of color as applied to earth materials -->
            <swe:identifier></swe:identifier>             <!-- does anything need to go in here? -->
            <swe:label>dark brown</swe:label>       <!-- a human-readable text label for the property value -->
            <swe:codeSpace xlink:href="http://resource.geosciml.org/classifierscheme/cgi/201201/color" xlink:title="CGI color vocabulary - version 2012.01"/>  <!-- URI and human-readable label for the vocabulary of color values. -->
            <swe:value>http://resource.geosciml.org/classifier/cgi/201201/color/dark_brown</swe:value<http://resource.geosciml.org/classifier/cgi/201201/color/dark_brown%3c/swe:value>>  <!-- URI to the unique identier for "dark brown" from the online vocabulary. -->
        </swe:Category>
    </gsmlem:color>
    <gsmlem:lithology xlink:href="http://resource.geosciml.org/classifier/cgi/simplelithology/sandstone" xlink:title="sandstone"/>
</gsmlem:RockMaterial>

Is this the correct (ie, best practice) encoding? Do we have all the infomation located in the correct attributes?  Does anything need to go in the swe:identifier element?

Regards,
Ollie
__________________________________________________________________

Ollie Raymond
Senior Geologist  - Information Management  |  Continental Geology Section
Minerals and Natural Hazards Division  |  GEOSCIENCE AUSTRALIA<http://www.ga.gov.au/>

Oceania Councillor & Interoperability Working Group
IUGS Commission for the Management and Application of Geoscience Information<http://www.cgi-iugs.org/>

Chair, GeoSciML Standards Working Group
Open Geospational Consortium<http://www.opengeospatial.org/projects/groups/geoscimlswg>
__________________________________________________________

Phone:  +61 2 6249 9575    Fax:  +61 2 6249 9971
Email:  Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>    Web:  www.ga.gov.au<http://www.ga.gov.au/>
Cnr Jerrabomberra Avenue and Hindmarsh Drive   Symonston   ACT
GPO Box 378   Canberra   ACT   2601   Australia

Applying geoscience to Australia's most important challenges


Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.
-------------------------------------------------------------------------------------------------------------------------

Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des informations confidentielles et/ou protegees ou dont la diffusion est restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. Astrium decline toute responsabilite en cas de corruption par virus, d'alteration ou de falsification de ce courriel lors de sa transmission par voie electronique.

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.

---------------------------------------------------------------------

Astrium SAS (393 341 516 RCS Nanterre) - Capital: 16.587.728 EUR - Siege social: 12 rue Pasteur, 92150 Suresnes, France


Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.
-------------------------------------------------------------------------------------------------------------------------

________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20130429/9cb7c394/attachment.htm>


More information about the GeoSciML mailing list