Skip to content

Commit

Permalink
[CI] Publish Documentation for 912be1e
Browse files Browse the repository at this point in the history
  • Loading branch information
NPJ-OP-LUX committed Jan 10, 2025
1 parent fb9b1d2 commit 2d96169
Show file tree
Hide file tree
Showing 20 changed files with 18,682 additions and 6,684 deletions.
11,718 changes: 11,718 additions & 0 deletions api/3.0/_attachments/specs/api-v3.yaml

Large diffs are not rendered by default.

Binary file added api/3.0/_images/api_connections.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
306 changes: 285 additions & 21 deletions api/3.0/index.html

Large diffs are not rendered by default.

40 changes: 24 additions & 16 deletions epo-wf/Business Process workflow/stage4/stage4.html

Large diffs are not rendered by default.

13 changes: 8 additions & 5 deletions epo-wf/Business Process workflow/stage5/stage5.html
Original file line number Diff line number Diff line change
Expand Up @@ -320,7 +320,10 @@ <h2 id="_business_view"><a class="anchor" href="#_business_view"></a>Business vi
<p><em>The Publishing Stable SDS Version with stakeholders business view diagram.</em></p>
</div>
<div class="paragraph">
<p>In the “Decide to release” Business Process, the Product Owner decides to release the latest ePO version release candidate as a stable release. In the “Update the documentation and publish the website” Business Process, the Product Owner removes the “rc” mark from the asciidoc pages of the documentation on the release/x.y.z branch of the <a href="https://github.com/OP-TED/epo-docs">OP-TED/epo-docs</a> repository. Consequently, the Documentation Website must be generated again to reflect this change.</p>
<p>In the “Decide to release” Business Process, the Product Owner decides to release the latest ePO version release candidate as a stable release.</p>
</div>
<div class="paragraph">
<p>In the “Update the documentation and publish the website” Business Process, the Product Owner removes the “rc” mark from the asciidoc pages of the documentation on the release/x.y.z branch of the <a href="https://github.com/OP-TED/epo-docs">OP-TED/epo-docs</a> repository. Consequently, the Documentation Website must be generated again to reflect this change.</p>
</div>
<div class="paragraph">
<p>On the <a href="https://github.com/OP-TED/ePO">OP-TED/ePO</a> repository, a release tag is created on the same commit as the latest release candidate tag in the “Mark the release version” business Process. Then, in the
Expand Down Expand Up @@ -360,7 +363,7 @@ <h2 id="_business_view"><a class="anchor" href="#_business_view"></a>Business vi
</ol>
</div>
<div class="paragraph">
<p>In the “Announce the release of the stable version” the Product Owner announces the release of the stable version to the community. The Product owner also contacts the <a href="https://op.europa.eu/en/web/eu-vocabularies">EU Vocabularies</a> (who are responsible for maintaining Cellar) and <a href="https://interoperable-europe.ec.europa.eu/collection/eprocurement/solution/eprocurement-ontology">Interoperable europe</a> teams, informing them of the latest release and works with them in order to publish the latest ontology release on their websites. For more information on EU Vocabularies and publishing to Cellar, look at the end of the document.</p>
<p>In the “Announce the release of the stable version” the Product Owner announces the release of the stable version to the community. The Product owner also contacts the <a href="https://op.europa.eu/en/web/eu-vocabularies">EU Vocabularies</a> (who are responsible for maintaining Cellar) and <a href="https://interoperable-europe.ec.europa.eu/collection/eprocurement/solution/eprocurement-ontology">Interoperable europe</a> teams, informing them of the latest release and works with them in order to publish the latest ontology release on their websites. For more information on EU Vocabularies and publishing to Cellar, look at the end of this page.</p>
</div>
</div>
</div>
Expand All @@ -385,13 +388,13 @@ <h3 id="_publishing_to_cellar"><a class="anchor" href="#_publishing_to_cellar"><
<p>In order to publish a release on <a href="https://op.europa.eu/en/web/cellar">Cellar</a>, TED provides One self-sufficient SDS distribution package for each ePO module In Cellar (ideally in the same structure as the one on GitHub) to the EU Vocabularies team. That package should be in the form of the <a href="https://op.europa.eu/en/web/eu-vocabularies/concept/-/resource?uri=http://publications.europa.eu/resource/authority/file-type/METS_ZIP">METS specification</a> and should contain Core, SHACL, restrictions, single HTML page documentation, deprecated URIs and change notes/release notes. The EU vocabularies team loads each module (including all the files) into Cellar as .OWL/.TTL/.HTML/.md files and does not activate ePO in Cellar (i.e. <a href="https://op.europa.eu/en/web/eu-vocabularies/cdm">the Cellar CDM model</a> is not affected by ePO).</p>
</div>
<div class="paragraph">
<p>There is a pending question on how to handle Dereferencing. Dereferenceable URIs are the backbone of Linked Data. They can be looked up (dereferenced) by both humans and machines to provide useful information about the resource that the URI identifies (in HTML for humans and RDF for machines), which in turn refers to other URIs, and so on. Please bear in mind that Reference documentation for the purpose of URI HTML dereferencing is not the same as Reference documentation for the purpose of including it into the TED Developer docs. The former must be a single page HTML document, the latter can be single or multi page AsciiDoc. Dereferencing as well Deprecation mechanisms are needed in order for an RDF graph to fullfill <a href="https://interoperable-europe.ec.europa.eu/collection/oeg-upm/news/fair-ontologies">FAIR publishing requirements</a>. The question is who should implement this, the ePO team or the Cellar team?</p>
<p>There is a pending question on how to handle Dereferencing. Dereferenceable URIs are the backbone of Linked Data. They can be looked up (dereferenced) by both humans and machines to provide useful information about the resource that the URI identifies (in HTML for humans and RDF for machines), which in turn refers to other URIs, and so on. Please bear in mind that Reference documentation for the purpose of URI HTML dereferencing is not the same as Reference documentation for the purpose of including it into the TED Developer docs. The former must be a single page HTML document, the latter can be single or multi page AsciiDoc. Dereferencing as well as Deprecation mechanisms are needed in order for an RDF graph to fullfill <a href="https://interoperable-europe.ec.europa.eu/collection/oeg-upm/news/fair-ontologies">FAIR publishing requirements</a>. The question is who should implement this, the ePO team or the Cellar team?</p>
</div>
<div class="paragraph">
<p>In case Cellar implements Dereferencing then, it may need to activate the ontology in order to dereference RDF, which can cause conflict with the CDM. If that is the case then alternative solutions should to be investigated. If a solution is found the Cellar also needs to provide a good HTML dereferencing mechanism, this shall point to a single HTML page in the style of <a href="https://respec.org/docs/">ReSpec</a>, <a href="https://github.com/dgarijo/Widoco">Widoco</a>,or a custom reference documentation.</p>
<p>If Cellar implements Dereferencing then, it may need to activate the ontology in order to dereference RDF, which can cause conflict with the CDM. If that is the case then alternative solutions should to be investigated. If a solution is found Cellar also needs to provide a good HTML dereferencing mechanism that should point to a single HTML page in the style of <a href="https://respec.org/docs/">ReSpec</a>, <a href="https://github.com/dgarijo/Widoco">Widoco</a>,or a custom reference documentation.</p>
</div>
<div class="paragraph">
<p>In case the ePO team implements Dereferencing, this will require a dedicated dereferencing server for both RDF and HTML. Also in this case, the ePO team should maintain Persistent URIs, in accordance with <a href="https://chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://interoperable-europe.ec.europa.eu/sites/default/files/inline-files/Towards-a-common-approach-for-the-management-of-persistent-URIs-by-EU-institutions_v.0.53.pdf">PURI conventions released by the European Commission in 2016</a> (see documents on EU <a href="https://www.w3.org/TR/cooluris/#semweb">Cool URI</a>), as well as maintain deprecated concepts for both RDF and HTML formats to fulfill persistence of the URIs.</p>
<p>If the ePO team implements Dereferencing, that will require a dedicated dereferencing server for both RDF and HTML. Also in this case, the ePO team should maintain Persistent URIs, in accordance with <a href="https://chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://interoperable-europe.ec.europa.eu/sites/default/files/inline-files/Towards-a-common-approach-for-the-management-of-persistent-URIs-by-EU-institutions_v.0.53.pdf">PURI conventions released by the European Commission in 2016</a> (see documents on EU <a href="https://www.w3.org/TR/cooluris/#semweb">Cool URI</a>), as well as maintain deprecated concepts for both RDF and HTML formats to fulfill persistence of the URIs.</p>
</div>
</div>
</div>
Expand Down
8 changes: 4 additions & 4 deletions epo-wf/SDS and related artefacts/SDSmodel2owl.html
Original file line number Diff line number Diff line change
Expand Up @@ -289,14 +289,14 @@ <h1 class="page">SDS artefact groups and purposes</h1>
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>In this section we explain purposes for artefacts (i.e. define requirements, in line with SEMIC style guide)</p>
<p>In this section we explain the purposes of the artefacts (i.e. define requirements, in line with SEMIC style guide)</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_purpose_1"><a class="anchor" href="#_purpose_1"></a>Purpose 1:</h4>
<div class="paragraph">
<p>“What artefacts are part of the ePO SDS to be distributed as a package”?
<p>“What artefacts are part of the ePO Semantic Data Specification to be distributed as a package”?
As seen in the figure below, these artefacts are:</p>
</div>
<div class="ulist">
Expand Down Expand Up @@ -338,7 +338,7 @@ <h4 id="_purpose_1"><a class="anchor" href="#_purpose_1"></a>Purpose 1:</h4>
<div class="sect3">
<h4 id="_purpose_2"><a class="anchor" href="#_purpose_2"></a>Purpose 2:<a id="P2"></a></h4>
<div class="paragraph">
<p>“What artefacts are parts of the ePO documentation?” As seen in the figure above, these artefacts are:</p>
<p>“What artefacts are parts of the ePO Semantic Data Specification documentation?” As seen in the figure above, these artefacts are:</p>
</div>
<div class="ulist">
<ul>
Expand Down Expand Up @@ -375,7 +375,7 @@ <h4 id="_purpose_2"><a class="anchor" href="#_purpose_2"></a>Purpose 2:<a id="P2
<div class="sect3">
<h4 id="_purpose_3"><a class="anchor" href="#_purpose_3"></a>Purpose 3:</h4>
<div class="paragraph">
<p>“What artefacts should be used for quality control while preparing the ePO SDS?” As seen in the figure below, these artefacts are:</p>
<p>“What artefacts should be used for quality control while preparing the ePO Semantic Data Specification?” As seen in the figure below, these artefacts are:</p>
</div>
<div class="ulist">
<ul>
Expand Down
9 changes: 7 additions & 2 deletions epo-wf/methodology/methodologyIndex.html
Original file line number Diff line number Diff line change
Expand Up @@ -302,11 +302,16 @@ <h1 class="page">Methodology</h1>
<p>Providing clarity on required artefacts, their purposes, and generation methods.</p>
</li>
<li>
<p>Applying simplified views of Business, Application, and Technology layers, with realised connections and support dependencies across layers.
This document does not include technical specifications of supporting tools, such as Model2Owl, Enterprise Architect UML Editor, GitHub Actions, Git clients, etc., or descriptions of procurement data models. Instead, the document focuses on the procedural framework, artefact requirements, and lifecycle stages suitable for ePO specific case, leaving the internal workings of associated technologies beyond its scope.</p>
<p>Applying simplified views of Business, Application, and Technology layers, with realised connections and support dependencies across layers.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>This document does not include technical specifications of supporting tools, such as Model2Owl, Enterprise Architect UML Editor, GitHub Actions, Git clients, etc., or descriptions of procurement data models. Instead, the document focuses on the procedural framework, artefact requirements, and lifecycle stages suitable for the ePO specific case, leaving the internal workings of associated technologies beyond its scope.</p>
</div>
<div class="paragraph">
<p>All the Archimate diagrams used for the workflow can be generated from the Enterprise Architect file found <a href="../_attachments/github-workflow.qeax">here</a>.</p>
</div>
</article>
<div id="widgetContainer">
<article class="widget">
Expand Down
Loading

0 comments on commit 2d96169

Please sign in to comment.