Documentation

use-cases/src/site/sphinx/architecture.rst

@@ -0,0 +1,7 @@
+.. _architecture:
+
+###############
+Architecture
+###############
+
+TBD

use-cases/src/site/sphinx/conf.py

@@ -7,6 +7,7 @@ version = '1.0'
 release = '1.0.0'
 
 # General options
+# themes https://sphinx-themes.org/
 needs_sphinx = '1.0'
 master_doc = 'suite'
 pygments_style = 'tango'

use-cases/src/site/sphinx/example.rst

@@ -4,6 +4,8 @@
 Example .rst File
 #################
 
+NB https://sphinx-design.readthedocs.io/en/furo-theme/dropdowns.html
+
 If you work with edX documentation source files, you might find this file
 helpful as a reference. This file contains examples of .rst formatting.
 

use-cases/src/site/sphinx/plugins.rst

@@ -0,0 +1,5 @@
+.. _plugins:
+
+###############
+Plugins
+###############

use-cases/src/site/sphinx/project.rst

@@ -5,17 +5,18 @@ Project Model
 ###############
 
 
-Each Project is defined as a JSON Document having the following sections :
+:doc:`suite` allows to manage the publication lifecycle of complex documents called **Projects** , i.e. documents made by :
 
-.. contents::
-  :Core Information:
-  :Lifecycle Information:
-  :Accounting Information:
-  :The Document:
-  :FileSets:1
-  :Manifestations:2
-  :Known Manifestations:3
+* A lot of different set of files (pdf, docs, imgs, GIS data, csv...)
+* A custom metadata model (title, author, repetible complex fields..)
 
+.. image:: _static/imgs/project.png
+   :alt: Project
+
+
+.. note:: Every **Project** is associated to a :doc:`ucd` that defines among other things its structure, its lifecycle, access rules etc..
+
+Each Project is defined as a JSON Document having the following sections
 
 ****************
 Core Information

use-cases/src/site/sphinx/quickstart.rst

@@ -0,0 +1,15 @@
+.. _quickstart:
+
+##########
+Quickstart
+##########
+
+.. seealso:: You can experiment with the application REST API at <swagger-link>
+
+
+*********
+Notebooks
+*********
+
+Checkout the guides at :file:`_notebooks`
+

use-cases/src/site/sphinx/suite.rst

@@ -1,55 +1,51 @@
 .. _suite:
 
-###############
-gCube CMS Suite
-###############
-
 .. _wiki: https://gcube.wiki.gcube-system.org/gcube/GeoPortal
 .. _gWiki: https://gcube.wiki.gcube-system.org/gcube/GeoPortal
 
-gCube CMS Suite is a distributed full stack application for publication management in a gCube Hybrid e-infrastructure.
 
-.. image:: https://gcube.wiki.gcube-system.org/images_gcube/e/e4/Geo_Portale%281%29.png
-   :scale: 50 %
+###############
+gCube CMS Suite
+###############
+.. note:: gCube CMS Suite is a gCube Application. Check more about gCube `here<https://www.gcube-system.org/>`_.
+
+**gCube CMS Suite** is a distributed full stack application for publication management in a gCube Hybrid e-infrastructure (see wiki `wiki`_).
+
+.. image:: _static/imgs/suite.png
    :alt: CMS Suite overall concept
 
-The gCube CMS Suite is a gCube Application designed to manage the publication workflow of complex documents (i.e. comprising of multi-level extensible metadata, attachments.. ) called Projects.
+
+*********
+The suite
+*********
+
+The **gCube CMS Suite** is a gCube Application designed to manage the publication workflow of complex documents (i.e. comprising of multi-level extensible metadata, attachments.. ) called Projects.
 It can manage the entire lifecycle of Projects, from their creation to access including :
 
+The gCube CMS Suite key features are :
 
-GeoPortal key features are :
-
-* Support for publication lifecycle
-  * By supporting complex Data (Meta + Payloads) archives known as ``:ref:`projects<_project>```;
-  * By enabling versioning, workflows, access policies;
-  * By supporting several manifestations (GIS, Databases, ...)
-  * By managing indexes (Meta catalogues, Index GIS layers)
-* Maximise re-usability
-  * By exploiting space-time GeoPortal Service
-  * By allowing for configurable behaviour;
-  * By supporting a generic meta-model;
-  * By offering configurable GUIs (Management grid, Insert/Edit Form, Data Viewers);
-* External Data Integration
-  * By exploiting OGC standards.
+- Support for publication lifecycle
+  -By supporting complex Data (Meta + Payloads) archives known as :doc:`project`
+  -By enabling versioning, workflows, access policies
+  -By supporting several manifestations (GIS, Databases, ...)
+  -By managing indexes (Meta catalogues, Index GIS layers)
+- Maximise re-usability
+  - By providing an extensible marketplace of plugins
+  - By allowing for configurable behaviour
+  - By supporting a generic meta-model
+  - By offering configurable GUIs (Management grid, Insert/Edit Form, Data Viewers)
+- External Data Integration
+  - By exploiting OGC standards.
 
+Contents of this guide :
+*************************
 
 .. toctree::
    :maxdepth: 2
 
-- CRUD operations
-- Role based access to Projects and lifecycle operations for moderation purposes
-- Dataset Materialization (e.g. Image preview, SDI support)
-- Dataset Indexing (e.g. ISO Metadata Catalogues, Centroids layers, CKAN)
-- Dataset Processing (e.g. DataMiner)
-- Customizable Insertion Forms, Navigation and Access GUIs
-
-Every 'project'_ is associated to a Use Case Descriptor, which defines :
-- Role based access and operation
-- 'project'_ validation schema
-- Involved plugins configuration (e.g. lifecycle type, materialization, GUIs)
-
-
-
-
-
-
+   quickstart
+   architecture
+   project
+   ucd
+   plugins
+   example

use-cases/src/site/sphinx/ucd.rst

@@ -0,0 +1,7 @@
+.. _ucd:
+
+###############
+Use Case Descriptors (UCD)
+###############
+
+TBD