Merge pull request #79 from OpenEnergyPlatform/develop

Update master with oem-v1.5.1

CHANGELOG.md

@@ -17,7 +17,7 @@ Here is a template for new release sections
 ### Removed
 -
 
-## [_._._] - 20XX-MM-DD
+## [0.0.0] - Release - Name of Release - 20YY-MM-DD
 
 ### Added
 -
@@ -32,40 +32,79 @@ Here is a template for new release sections
 
 ### Changed
 
-## [1.5.0] - Release 
+
+## [1.5.1] - Release - Ontology-Ready - 2022-02-21
+
+### Added
+- Use  [GitHub projects](https://github.com/OpenEnergyPlatform/oemetadata/projects) to organise releases
+- Add new example table to show connection to OEO
+- Add test for latest directory to CI [PR#74]
+
+### Changed
+- Update ``subject`` to work with OEO
+- Rename and update ``isAbout`` to work with OEO
+- Rename and update ``valueReference`` to work with OEO
+- Improve documentation
+- Update schema.json
+- Update CHANGELOG.md and give names to releases
+- Update CONTRIBUTING.md
+
+## [1.5.0] - Release - Get Some Semantics - 2021-11-18
 
 ### Added
 - Add keys for linked data compatibility: ``@context``, ``@id``, ``subject``, ``is_about``, ``value_reference``
 - Add context.json file 
+- Add licence information to README.md
 
 ### Changed
-- Delete future directory
 - Clarify instructions for dealing with non-applicable keys (null) and missing values ("todo")
 - Make key 13.2 ``timeseries`` a list
 - Relocate development information from README.md to CONTRIBUTING.md 
-- Add licence information to README.md
 - Update all .json files to v1.5.0
-- reintroduce automated tests (CI) by switching form travis-ci to github actions [PR#63]
-- Updated schema.json for v1.5.0 now includes the new key "title" which describes the title of the curent field [PR#56] adapted from [PR#43]
+- Reintroduce automated tests (CI) by switching form travis-ci to github actions [PR#63]
+- Updated schema.json for v1.5.0 now includes the new key ``title`` which describes the title of the curent field [PR#56] adapted from [PR#43]
 
-## [1.4.1] - Minor release 2021-01-14
+### Removed
+- Delete future directory
+
+## [1.4.1] Minor Release - Repo Upgrade - 2021-01-18
 
 ### Added
-- New directory for release version 1.4.1
-- Added test for version 1.4.1
-- Add Current section to Changelog, documenting all changes in current branch and stage for release
+- Add directory for v1.4.1
+- Add tests for v1.4.1
+- Add current section to Changelog, documenting all changes in current branch and stage for release
 - Extend black options, COMMAND tox -v now shows exactly what code must be reformatted
 
 ### Changed
 - Rename repository from "metadata" to "oemetadata"
 
-## [1.0.1] Initial release
+## [1.4.0] Release - It'll be a standard - 2021-01-11
+
+### Added
+- Add ``timeseries`` to ``temporal``
+- Add ``context`` object for project information
+- Add ``object`` to ``contributors`` to decide between data and metadata
+- Add ``profile`` to ``resources`` according to datapackage standard
+- Add ``encoding`` to ``resources`` according to datapackage standard
+- Add ``schema`` to ``resources`` according to datapackage standard
+- Add ``type`` to ``fields`` for data types
+- Add ``primaryKey``
+- Add ``foreignKeys``
+- Add ``dialect``
+- Add ``review``
+- Add ``metaMetadata``
+- Add ``_comment``
+
+### Changed
+- Rename ``url`` to ``path`` according to datapackage standard
+
+## [1.0.1] Initial Release - Hello OEMetadata - 2019-11-07
 
 ### Added
 
-- v130 metadata schema, example, template
-- v140 metadata schema, example, template
-- Python implementation and tests for schema, example, template of v130
-- Python implementation and tests for schema, example, template of v140
+- OEMetadata version v1.3.0 metadata schema, example, template
+- OEMetadata version v1.4.0 metadata schema, example, template
+- Python implementation and tests for schema, example, template of v1.3.0
+- Python implementation and tests for schema, example, template of v1.4.0
 - Implementation of metaschema (draft07) and test of metaschema
 

CONTRIBUTING.md

@@ -1,49 +1,108 @@
-## Development
+## Collaborative Development
 
 ### Prerequisites
 
 - [Git](https://git-scm.com/)
 
 
-### Philosophy
+### Workflow
 
-Development of a feature for this repository should follow the workflow described 
-by [Vincent Driessen](https://nvie.com/posts/a-successful-git-branching-model/).
+The workflow for contributing to this project has been inspired by the workflow described by [Vincent Driessen](https://nvie.com/posts/a-successful-git-branching-model/).
 
-Here are the minimal procedure you should follow : 
 
-#### Step 1: Describe the issue on github
+#### Step 1: Describe the issue on GitHub
 
 Create [an issue](https://help.github.com/en/articles/creating-an-issue)
-on the github repository, describing the problem you will then address
-with your feature/fix. This is an important step as it forces one to
-think about the issue (to describe an issue to others, one has to think
-it through first).
+in the GitHub repository. The `issue title` describes the problem you will address. This is an important step as it forces one to think about the "issue".
 
 #### Step 2: Solve the issue locally
 
-1. Create a separate branch from `develop`, to work on
-    ```bash
-    git checkout -b feature/myfeature develop
-    ```
-    The convention is to always have `feature/` in the branch name. The `myfeature` part should describe shortly what the feature is about (separate words with `_`).
-
-2. Try to follow [these conventions](https://chris.beams.io/posts/git-commit) for commit messages:
-    - Keep the subject line [short](https://chris.beams.io/posts/git-commit/#limit-50) (i.e. do not commit more than a few changes at the time)
-    - Use [imperative](https://chris.beams.io/posts/git-commit/#imperative) for commit messages 
-    - Do not end the commit message with a [period](https://chris.beams.io/posts/git-commit/#end) 
-        You can use 
-        ```bash
-        git commit --amend
-        ```
-        to edit the commit message of your latest commit (provided it is not already pushed on the remote server).
-        With `--amend` you can even add/modify changes to the commit.
-
-3. Push your local branch on the remote server `origin`
-    ```bash
-    git push
-    ```
-    If your branch does not exist on the remote server yet, git will provide you with instructions, simply follow them.
+##### 0. Get the latest version of the `develop` branch
+
+```bash
+git checkout develop
+```
+
+```bash
+git pull
+```
+
+##### 1. Create a new (local) branch
+
+```bash
+git checkout -b feature-1314-my-feature
+```
+
+**Naming convention** for branches: `type`-`issue-nr`-`short-description`
+
+**type**
+
+* master / main / stable - includes the current stable version
+* dev - includes all current developments
+* feature - includes the feature that will be implemented
+* hotfix - includes small improvements before an release, should be branched from a release branch
+* release - includes the current version to be released
+
+The majority of the development will be done in `feature` branches.
+
+**issue-nr**
+
+The `issueNumber` should be taken from Step 1. Do not use the "#". 
+
+**short-description**
+
+Describe shortly what the branch is about. Avoid long and short descriptive names for branches, 2-4 words are optimal.
+
+Other hints:
+- Separate words with `-` (minus)
+- Avoid using capital letters
+- Do not put your name to the branch name, it's a collaborative project
+- Branch names should be precise and informative
+
+Examples of branch names : `feature-42-add-new-ontology-class` or `feature-911-branch-naming-convention`
+
+##### 2. Start editing the files
+
+- Divide your feature into small logical units
+- Start to write the documentation or a docstring
+- Don't rush, have the commit messages in mind
+
+
+##### 3. Commit your changes 
+
+```bash
+git commit filename.md
+``` 
+
+- Follow [existing conventions for commit messages](https://chris.beams.io/posts/git-commit)
+- Keep the subject line [shorter than 50 characters](https://chris.beams.io/posts/git-commit/#limit-50)
+- Do not commit more than a few changes at the time: [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit)
+- Use [imperative](https://chris.beams.io/posts/git-commit/#imperative)
+- Do not end the commit message with a [period](https://chris.beams.io/posts/git-commit/#end) ~~.~~ 
+
+##### 3.2 Fix your latest commit message
+
+You want to improve your latest commit message? Your latest commit is not pushed yet? 
+Edit the commit message of your latest commit
+
+```bash
+git commit --amend
+```
+
+
+##### 4. Push your `local` branch on the remote server `origin`
+
+If your branch does not exist on the remote server yet, use:
+
+```bash
+git push --set-upstream origin feature-1314-my-feature
+```
+
+Then push regularly with:
+
+```bash
+git push
+```
 
 
 #### Step 3: Run tests locally
@@ -97,7 +156,7 @@ pip install -r requirements.txt
 
 #### Step 4: Submit a pull request (PR)
 
-Follow the [steps](https://help.github.com/en/articles/creating-a-pull-request) of the github help to create the PR.
+Follow the [steps](https://help.github.com/en/articles/creating-a-pull-request) of the GitHub help to create the PR.
 Please note that you PR should be directed from your branch (for example `myfeature`) towards the branch `dev`.
 
 Add a line `Fix #<number of the issue created in Step 2.0>` in the
@@ -115,7 +174,7 @@ you can add the bash commands under `# command to run tests` of the
 `.travis.yml` file. For this you need to have an account by
 [Travis](https://travis-ci.org/) and link your repo to their service.
 Soon [GitHub action](https://github.com/features/actions) might take
-care of this directly within github.
+care of this directly within GitHub.
 
 In the `.travis.yml` file are many options commented out, you can have
 very complexe schemes to test on many different python versions etc. For

README.md

@@ -1,11 +1,11 @@
-[![Build Status](https://travis-ci.org/OpenEnergyPlatform/oemetadata.svg?branch=develop)](https://travis-ci.org/OpenEnergyPlatform/oemetadata)
+[![Automated tests](https://github.com/OpenEnergyPlatform/oemetadata/actions/workflows/metadata-test.yml/badge.svg)](https://github.com/OpenEnergyPlatform/oemetadata/actions/workflows/metadata-test.yml)
 
 <a href="https://github.com/OpenEnergyPlatform/oemetadata/"><img align="right" width="100" height="100" src="https://raw.githubusercontent.com/OpenEnergyPlatform/organisation/master/logo/OpenEnergyFamily_Logo_OEMetadata.png" alt="OpenEnergyMetadata"></a>
 <a href="https://openenergy-platform.org/"><img align="right" width="100" height="100" src="https://avatars2.githubusercontent.com/u/37101913?s=400&u=9b593cfdb6048a05ea6e72d333169a65e7c922be&v=4" alt="OpenEnergyPlatform"></a>
 
-# Open Energy Family - Open Energy Metadata (OEM)
+# Open Energy Family - Open Energy Metadata (OEMetadata)
 
-Open Energy Metadata (OEM) is an energy metadata standard including a template, examples and a metadata schema.
+Open Energy Metadata (OEMetadata) is an energy metadata standard including a template, examples and a metadata schema.
 It is an extensive set of metadata based on the tabular data package specifications and the FAIR principles.
 The metadata contains multiple fields (keys) in a nested JSON structure.
 

metadata/latest/context.json

@@ -7,7 +7,7 @@
         "xsd": "http://www.w3.org/2001/XMLSchema#",
         "oeo": "http://openenergy-platform.org/ontology/oeo/",
         "csvw": "http://www.w3.org/ns/csvw#",
-        "obo":"http://purl.obolibrary.org/obo/",
+        "obo": "http://purl.obolibrary.org/obo/",
         "title": {
             "@id": "dct:title",
             "@type": "xsd:string"
@@ -53,4 +53,4 @@
             "@type": "@id"
         }
     }
-}
+}