Design new system, which documentation data is kept is in version package dir

[kurzum]

currently only minimal information is kept in the export package.
Feature to be designed:

• reproduce state of version on mvn deploy to redo amend, force-push updates
• define on which operations (re-deploy) what can be change and how

Some things need to be updated globally, e.g. attributed by, e.g. take last version or manage centrally.
(git solves it by link to newest version)

Task: problem and requirements not well defined yet (wie man es genau haben will)

[kurzum]

Some ideas:

• having the groupdocu in the group pom.xml still seems practical. I really didn't understand what the reason for the conflict is with the initeval dataset. It really sounds like that one artifact in the group is so different, that it needs its own group docu, but in this case it doesn't make sense to use the group docu for this. The info should be in the artifact dc:description then.
• before the group docu was appended to the markdown, but this caused more problems. It is much better separated.
• in the end we need to copy/preserve the following files on mvn package

1. group pom (deleting any credentials)
2. artifact pom
3. artifact md
4. provenance.tsv
   On the other hand all four of them are included in the dataid.ttl, so if we implement round-trip back (separating groupdocu helped a lot here) that should solve it. @Vehnem found a good library here, which makes it a couple days of work. Note that I asked Natanael whether he is interested to implement a html page.

Overall, I don't see any conceptual problems. @JJ-Author you would need to specify requirements here. While we can implement round-trip, there are many details left, like should we overwrite the group pom.xml. So operationally, this needs some use cases with clear stories and a good description of what happens there.

[kurzum]

https://github.com/dbpedia/databus-content/blob/master/group_labels_comments.ttl is actually the only thing which is not version specific. They are just two properties to make it more user-friendly, i.e. they determine how stuff is shown on the website. No harm done to the release model as such. We could limit group rdfs:comment to 100 chars. Or merge the group docu into it (although this seems weird)