[GeoSciML] deferred issues from Dublin SWG [SEC=UNCLASSIFIED]

Raymond Oliver Oliver.Raymond at ga.gov.au
Thu Jun 30 19:32:30 EDT 2016


Yep.

From: GeoSciML [mailto:geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org] On Behalf Of Boisvert2, Eric (NRCan/RNCan) via GeoSciML
Sent: Friday, 1 July 2016 9:23 AM
To: Boisvert2, Eric (NRCan/RNCan); 'Public: A mailing list for GeoSciML'
Subject: Re: [GeoSciML] deferred issues from Dublin SWG

> I propose to move the "Lite" section after their other package (instead of being the first)

Looks like we have unanimous abstention.  So I'll go forward and move Lite after the other GeoSciml requirements classes



From: GeoSciML [mailto:geosciml-bounces+eric.boisvert2=canada.ca at lists.opengeospatial.org] On Behalf Of Boisvert2, Eric (NRCan/RNCan) via GeoSciML
Sent: Saturday, June 25, 2016 11:13 AM
To: 'Public: A mailing list for GeoSciML'
Subject: [GeoSciML] deferred issues from Dublin SWG

All,

Of the list of issues we had a discussion item that we chose to defer because we were running out of time:



p. 35 , first paragraph:

. In robust services the free-text fields will contain well-structured summaries of data in a format suitable for reading by the intended users
This comes from the scope note and I don't understand what "robust services" and "well-structured" are.
Rephrase and turn into recommendation.  [Ollie - "Best practice is that free text fields will, where possible, contain well-structured summaries of data in a format suitable for reading by the intended users.  For instance, an agreed common format like comma-delimited values should be adopted by user communities."]  *DECISION: Defer to later*
There are divergences on the necessary to keep this clause (text might be well structured .  It can be understood as

-          0,,* fields merged into a single string could be individualized back by the client (eg: two ages separated by commas, comma being the separation character)

-          And/or field can contain structured data (eg: like JSON, or - ironically, XML).

-          The second case is like using Lite to deliver complex data (why not use complex model then ?).

-          We need to decide if a) we even need to mention it (so delete discussion), b) make a recommendation for either first and/or second case, c) make a requirement for fields that are indeed collation of several fields.

-

Also: since we concluded that Portrayal (Lite) is a transformation of Complex Model, I propose to move the "Lite" section after their other package (instead of being the first)


Carlo sent me a correction for GeoMorphologicalUnit instance example which I will integrate to the document shortly.



Eric Boisvert, MSc

Professionnel de Recherche - Reseach Officer
Commission géologique du Canada - Geological Survey of Canada
Secteur des sciences de la terre - Earth Science Sector
Ressources naturelles Canada - Natural Resources Canada

490 de la Couronne
Québec, Qc, Canada
G1K 9A9

T: 1-418-654-3705 F: 1-418-654-2615
E: eric.boisvert2 at canada.ca<mailto:eric.boisvert2 at canada.ca>
http://orcid.org/0000-0001-6256-2912


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.
-------------------------------------------------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20160630/89198965/attachment-0001.html>


More information about the GeoSciML mailing list