in-progress processing

Author: ghobona

part1_core/document.asciidoc.log.txt

@@ -446,92 +446,204 @@ W3C XPath will be used in XML instances.  XML entities will be identified using
 * `gsmlb:GeologicUnit/gml:name/@codeName` refers to the codeName attribute of the name property of GeologicUnit
 
 [obligation=informative]
-== Clauses not containing normative material
+== GeoSciML Models
 
-Paragraph
+=== GeoSciML Models
 
-=== Clauses not containing normative material sub-clause 1
+The GeoSciML 4.1 is an ISO General Feature Model (ISO19101, ISO19109) implementation of portions of the North American Data Model ++[++12++]++ and CSIRO’s XMML model.  GeoSciML also provides models for concepts at the immediate periphery of geological mapping, such as boreholes, geologic specimens and laboratory analysis, modelled as SF++_++SamplingFeatures and OM++_++Observations (OGC 10-004r3). 
 
-Paragraph
+.Model lineage. Geological entities are logical implementations of NADM while sampling and observations entities are implementations of O&M (ISO19156).
+image::images/image1.png[width=601,height=520]
+
+
+GeoSciML has been through 4 major releases and a few minor releases since 2005.  Each version brought a different interpretation of what is essentially the same conceptual model.  The reader looking at all iterations will see, with few exceptions, the same concepts, the same associations and the same properties, but packaged differently.  GeoSciML increasingly adopted other domain models as it evolved; it replaced XMML (eXploration and Mining Markup Languages, developed by CSIRO) by Observations and Measurements (ISO19156), custom data types for ranges and categories by SWE Common, and removed custom vocabularies to use web resources.
+
+This fourth iteration is essentially a repackaging of the previous version 3.2 from 13 packages organised by themes into 6 packages organised by use cases (Figure 2):
+
+* *GeoSciML Basic*: a set of core geologic features, aligned to the INSPIRE Data Specification on Geology.
+* *GeoSciML Extension*: an extension providing detailed description of basic features which adds additional properties and associations.
+* *GeoSciML Geologic Age*: a model for the representation of geologic time using procedures adopted by the International Stratigraphic Commission.
+* *GeoSciML Borehole*: a model for boreholes, including geologic logs and drilling details and other engineering information.
+* *GeoSciML Laboratory and Analysis*: a model for laboratory analytical metadata, geological sampling and specimens, and isotopic age observation results.
+* *GeoSciML Lite*: previously known as “GeoSciML Portrayal” in version 3.2; a simplified alternate implementation of the conceptual model for layer based applications.
+
+.GeoSciML 4.1 packages
+image::images/image2.png[width=601,height=525]
+
+ Each application package is the subject of at least one requirements class (to conform to the modular specification) per target implementation (this specification has three targets; logical model, encoding and data instance).  More target implementations might be published as separate documents.
+
+=== GeoSciML Basic and Extension
+
+GeoSciML describes geological features from the mapping perspective, articulated around the concept of a MappedFeature – the cartographic element shown on a map, and the GeologicFeature it represents.  All geologic concepts that can be represented on a map are subtypes of GeologicFeature.
+
+.High-level model
+image::images/image3.png[width=562,height=330]
+
+GeologicFeature is an abstract class materialised into four concrete classes (Figure 4) - GeologicEvent, GeologicStructure, GeologicUnit and GeomorphologicFeature.   The other main features of the GeoSciML model are not geologic features themselves, but features related to the activity of sampling and observing geology (such as Borehole or GeologicSpecimen) and are therefore modelled as SF++_++SamplingFeature (O&M) subtypes.
+
+.Core feature model for GeoSciML
+image::images/image4.png[width=601,height=333]
+
+GeologicFeature can share arbitrary relationships through a relation class (AbstractRelation), subtyped into different kind of relationships, providing distinct properties and constraints.
+
+In order to provide a simple entry level model for data providers, but also to align to INSPIRE, only a minimal set of properties are supported by the _basic_ package.  When more properties are required, the data provider can use the _extension_ package.  To split properties between _basic_ and _extension_, a modelling pattern has been adopted to overcome the limitations of classical object oriented subtyping imposed by UML and XSD.
+
+==== AbstractDescription classes
+
+The technique to add extended properties to an existing class is normally to create a subtype to carry the new properties (Figure 5).
+
+.Adding properties by extension
+image::images/image5.png[width=601,height=892]
 
-=== Clauses not containing normative material sub-clause 2
+But this only works when properties need to be added to a leaf class.  Properties added by subtyping a class higher up in the chain of inheritance will create a new branch, and new properties won’t propagate to existing subtypes in the main branch. GeoSciML 4 adopts an extension pattern using abstract property blocks or ‘AbstractDescription’ classes (Figure 6).  Blocks of extended properties are organized in their own Datatype, subtyping AbstractDescription.
+
+.Extension pattern using a property block (AbstractDescription class)
+image::images/image6.png[width=601,height=300]
+
+This pattern has two main advantages:
+
+* It does not require the creation of a new feature type to add properties to core features.
+* Extra properties can be defined and used by other user communities (e.g., properties added by a geophysical application could be reused by groundwater applications).
+
+GeoSciML Basic contains nine stub AbstractDescription classes ultimately materialised in GeoSciML Extension (Table 1).
+
+[width="100%",cols="^50%,^50%",options="header",]
+|===
+|*Table 1: GeoSciML Basic stub AbstractDescription classes.* |
+|*Class* |*Description*
+|*AbstractFeatureRelation* |Association class placeholder to describe relations between geologic features.
+|*EarthMaterialAbstractDescription* |Detailed earth material description placeholder for GeologicUnit and EarthMaterial.
+|*GeologicUnitAbstractDescription* |Detailed description placeholder for GeologicUnit.
+|*GeologicEventAbstractDescription* |Detailed description placeholder for GeologicEvent.
+|*ContactAbstractDescription* |Detailed description placeholder for Contact.
+|*FoliationAbstractDescription* |Detailed description placeholder for Foliation.
+|*FoldAbstractDescription* |Detailed description placeholder for Fold.
+|*ShearDisplacementStructureAbstractDescription* |Detailed description placeholder for ShearDisplacementStructure.
+|*GeomorphologicUnitAbstractDescription* |Detailed description placeholder for GeomorphologicUnit.
+|===
+
+Since those classes are abstract in GeoSciML Basic, data providers need to implement GeoSciML Extension, or any third party extension to get concrete classes.
+
+This modelling pattern is also used by other standards communities (e.g., ISO 19115-3).
+
+=== GeoSciML Lite
+
+GeoSciML Lite is a denormalised view, or a transformation, of key geological and sampling features, designed as a simple entry-level model to publish datasets, particularly adapted to geographic visualization with key reporting properties.  The use case for GeoSciML Lite is a simple layer-based application; such as web map application or GIS where the key functionality is to display a map layer and perform simple identify or query operations.  The classes are modelled to be easily implementable in any GIS or web mapping application.  One feature type maps to one table composed of optional, single-occurrence properties – consistent with the structure of denormalised RDBMS tables.  The XML implementation (clause 9.8) is conformant with GML Simple Feature (OGC 10-100r3).
+
+Each property of GeoSciML Lite classes is derived from a subset of the properties available in the full GeoSciML model, with the exception of “genericSymbolizer”, which is a convenience property providing a cartographic symbol or code. The property is a shortcut to symbolisation that would otherwise be provided by an SLD (Styled Layer Descriptor).
+
+Some fields are external references, in the form of HTTP URI, to provide hyperlinks for applications to access linked data definitions to externally governed vocabulary terms and/or complex representations of the features when required.
+
+.Example of linkage between a GeoSciML Lite feature and other GeoSciML packages and vocabulary term URI’s.  An instance of GeologicUnitView matches an instance of MappedFeature
+image::images/image7.png[width=571,height=413]
 
 [obligation=informative]
-== Clauses not containing normative material
+== Conceptual Model
+
+The strictly geological portion of GeoSciML, as opposed to the parts dealing with sampling (e.g., boreholes) and laboratory metadata, is largely an implementation of the North American Data Model ++[++12++]++.  NADM is a technologically neutral conceptual model that addresses geoscience concepts and the relationships between them.  GeoSciML 4 does not implement NADM Geologic Portrayal (a model of cartographic elements composing a geological map, such as legends, symbols, insets, etc.) nor Geologic Vocabulary (although older versions of GeoSciML did).
+
+GeoSciML is an ISO Feature Model implementation of NADM and this created subtle differences between NADM and GeoSciML as the logical model deals with ISO Feature Model idiosyncrasies.  For instance, NADM multiple inheritances used in Fossil could not be implemented in the ISO world that forbids such constructs.  There were also conceptual changes, especially regarding EarthMaterial that is not considered as a GeologicFeature (hence an ISO FeatureType) in GeoSciML, but as a Type.
+
+Sampling and analytical metadata features (Borehole and GeologicSpecimen in particular) are extensions of Observations and Measurements (10-004r3) and as such implement the underlying Observations and Measurements conceptual model.  Borehole introduces engineering concepts known to the industry without a formal conceptual model.  It has been recognised that Boreholes are features that are common outside the geological mapping realms (like the energy and mineral resources industries, hydrogeology, civil engineering, etc) and more formal work could be carried by those interested parties.  Therefore, Borehole in GeoSciML is a essentially placeholder waiting to be replaced by a more formal Borehole model that is applicable across more domains than geology. It is expected that the Laboratory Analysis model could also be formalised by parties interested in (geo)chemical analysis. 
+
+[width="100%",cols="9%,91%",options="header",]
+|===
+|*Requirements class* |
+|/http://www.opengis.net/spec/waterml/2.0/req/xsd-xml-rules[*[.underline]#req/gsml4-conceptual#*] |
+|*Target type* |Logical Model
+|*Name* |GeoSciML conceptual model
+|*Dependency* |ISO19101:2002 Reference Model Clause 7
+|*Dependency* |ISO19103 2015 Conceptual Model Language
+|*Dependency* |ISO19104:2008
+|*Dependency* |Unified Modeling Language (UML). Version 2.3. May 2010
+|*Requirement* a|
+*/req/gsml4-conceptual/similarity*
+
+A target logical model, when claiming compliance with this conceptual model, SHALL implement its components (classes, attributes, relationships) respecting the conceptual model definitions and intent, such that high semantic similarity is obtained between the logical and conceptual model components.
+
+|===
+
+Target logical models that are compliant with the conceptual model shall implement components of the conceptual model respecting their semantics, i.e. their definition and intent. In other words, the logical model must be highly semantically similar to components of the conceptual model. Semantic similarity can be tested in multiple ways, including but not limited to: (i) direct comparison of UML components, (ii) comparison after mapping components to a common expressive knowledge representation language, such as first order logic or common logic, or (iii) comparison after mapping components to a reference ontology. The target can reuse and adapt existing logical models.
+
+[width="100%",cols="100%",options="header",]
+|===
+|*Requirement /req/gsml4-conceptual/similarity*
+|A target logical model, when claiming compliance with this conceptual model, SHALL implement its components (classes, attributes, relationships) respecting the conceptual model definitions and intent, such that high semantic similarity is obtained between the logical and conceptual model components.
+|===
+
+== Logical Model
+
+=== Logical Model
 
 Paragraph
 
-=== Clauses not containing normative material sub-clause 1
+==== Requirement Class A or Requirement A Example
+
+TBA
+
+=== Logical Model
 
 Paragraph
 
-=== Clauses not containing normative material sub-clause 2
+==== Requirement Class A or Requirement A Example
+
+TBA
 
-== Clause containing normative material
+=== Logical Model
 
 Paragraph
 
-=== Requirement Class A or Requirement A Example
+==== Requirement Class A or Requirement A Example
 
-Paragraph – intro text for the requirement class.
+TBA
 
-Use the following table for Requirements Classes.
+=== Logical Model
 
-[[req_class_a]]
+Paragraph
 
-[requirements_class]
-.Requirements Class 'A'
-====
-[%metadata]
-identifier:: link:++http://www.opengis.net/spec/ABCD/m.n/req/req-class-a++[]
-subject:: Web API
-requirement:: /req/req-class-a/req-name-1
-requirement:: /req/req-class-a/req-name-2
-====
+==== Requirement Class A or Requirement A Example
 
+TBA
 
+=== Logical Model
 
-==== Requirement 1
+Paragraph
 
-Paragraph - intro text for the requirement.
+==== Requirement Class A or Requirement A Example
 
-Use the following table for Requirements, number sequentially.
+TBA
 
-[[req_class_a_name_1]]
+=== Logical Model
 
-[requirement]
-====
-[%metadata]
-identifier:: /req/req-class-a/req-name-1
-part:: Requirement 'shall' statement
-====
+Paragraph
 
-Dictionary tables for requirements can be added as necessary. Modify the following example as needed.
+==== Requirement Class A or Requirement A Example
 
-[width="90%",options="header"]
-|===
-|Names |Definition |Data types and values |Multiplicity and use
-|name 1 |definition of name 1 |float |One or more (mandatory)
-|name 2 |definition of name 2 |character string type, not empty |Zero or one (optional)
-|name 3 |definition of name 3 |GML:: Point PropertyType |One (mandatory)
-|===
+TBA
 
+=== Logical Model
 
-==== Requirement 2
+Paragraph
 
-Paragraph - intro text for the requirement.
+==== Requirement Class A or Requirement A Example
 
-Use the following table for Requirements, number sequentially.
+TBA
 
-[[req_class_a_name_2]]
+=== Logical Model
 
-[requirement]
-====
-[%metadata]
-identifier:: /req/req-class-a/req-name-2
-part:: The server SHALL support process input values encoded as qualified values.
-part:: The value of the `value` key SHALL be an _object_ instance.
-====
+Paragraph
+
+==== Requirement Class A or Requirement A Example
+
+TBA
+
+=== Logical Model
+
+Paragraph
+
+==== Requirement Class A or Requirement A Example
+
+TBA
 
 ////
 add or remove annexes after "A" as necessary