Skip to content

Commit

Permalink
Applying changes from commit 3187a596f30330d524e498ba11101e0577f05ae9
Browse files Browse the repository at this point in the history
  • Loading branch information
Circle CI Builder committed Dec 11, 2024
1 parent 7cd19af commit 90beeb6
Show file tree
Hide file tree
Showing 10 changed files with 410 additions and 346 deletions.
Binary file added Reporting-Requirements-Metadata-Vocabulary/releases/0.0.2/html/SORTISmodel.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
58 changes: 45 additions & 13 deletions Reporting-Requirements-Metadata-Vocabulary/releases/0.0.2/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4286,15 +4286,6 @@ <h3 id="cr4">Separate information on usage of a concept from the definition to a
<h3 id="cr5">Separate code list from the model to make their lifecycle management independent</h3>
Added the codelists to section [[[#controlled-vocs]]].
<p class="ednote" title="use of dct:type">
The property rrmv:hasType is not discriminating between the constraints of the domains Action Result, Role, Agent.
That makes it equivalent to the generic property dct:type.
<p/>
Proposal 1. replace rrmv:hasType with dct:type
Proposal 2: replace rrmv:hasType with 3 subproperties of dct:type.
<p/>
As long no additional constraints like additional usage constraints, such as <i> in case X, then Y must be provided</i> or cardinality constraints with a qualified usage for a specific codelist, proposal 1 is fine. However for implementers of an editorial interface Proposal 2 may be more stable and attractive.
</p>
<p class="ednote" title="URI for code in codelists">
It is recommended to manage the URIs for the codelists in a separate namespace.
Expand Down Expand Up @@ -4329,10 +4320,9 @@ <h3 id="cr7">Reduce the number of connectors and associated classes by using att
<ul>
<li> rrmv:hasTitle becomes dct:title </li>
<li> replace range xsd:string with a language aware string literal as range. </li>
<li> replace rrmv:hasTemporalEntity with rrmv:hasUnit </li>
<li> the property rrmv:hasTemporalEntity and class TemporalEntity are replaced with rrmv:hasUnit refering to a to be determined codelist</li>
</ul>
</p>
Expand All @@ -4353,8 +4343,50 @@ <h3 id="cr8">Consider “Request” as a separate entity from eli:LegalExpressio
</p>
<h3 id="cr8">Introduction of the ExecutionRequest, ExecutionAction and ExecutionActionResult </h3>
This is applied in a seperate next version to avoid interference with other changes.
This is applied in a separate next version to avoid interference with other changes.
<h3 id="cr9">New Change Requests</h3>
<h4 id="cr9a">Temporal information </h4>
In the model a Request has a frequency and an Action happens at a time.
The sentence "6 months after the directive enters into force, the MS must provide a report containing ... every two years."
In this sentence the frequency is "every two years", while "6 months after the directive enters into force" is the start date.
The question resides why this information is associated with the Action and the frequency is associated with the more conceptual entity Request.
<h4 id="cr9b">Temporal information:Frequency </h4>
The EU Vocabularies contains a codelist for <a href="https://op.europa.eu/en/web/eu-vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/frequency">frequencies</a>.
It should be considered if this codelist is not better suited to address the usecase of the class Frequency.
<h4 id="cr9c">annotations </h4>
The process of dectecting the RRMV concepts in legislation is a two step process.
The first is textual analysis in which the relevant text in the legistation is identified and associated with the RRMV concepts.
Based on this textual representation each RRMV concept is then turned into a machine readible representation.
<p/>
In the current RRMV this first phase is not universally applied. It seems as if an Agent could be determined as machine readible
information without this text analysis.
<p/>
Proposal to create a metaclass: rrmv:TextualAnalysis which intention is to capture all information to enable text to structured information transformation.
Introducing this supporting class will make the model more readible, condense and it makes abstraction of the indiviual transformation case.
E.g. The same input information is available for Actions as for Frequencies or Agents.
<p/>
Additionally the current approach applies a copying approach. Namely the identified highlighted text is stored in an annotation.
There exists an approach to have the hightlighted annotations not stored in an extracted way but as a reference in the text: <a href="https://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core/nif-core.html">NIF</a>.
<h4 id="cr9d">use of dct:type instead of own minted properties</h4>
The property rrmv:hasType is not discriminating between the constraints of the domains Action Result, Role, Agent.
That makes it equivalent to the generic property dct:type.
<p/>
Proposal 1. replace rrmv:hasType with dct:type
Proposal 2: replace rrmv:hasType with 3 subproperties of dct:type.
<p/>
As long no additional constraints like additional usage constraints, such as <i> in case X, then Y must be provided</i> or cardinality constraints with a qualified usage for a specific codelist, proposal 1 is fine. However for implementers of an editorial interface Proposal 2 may be more stable and attractive.
</p>
Expand Down
58 changes: 45 additions & 13 deletions Reporting-Requirements-Metadata-Vocabulary/releases/0.0.2/index_en.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4286,15 +4286,6 @@ <h3 id="cr4">Separate information on usage of a concept from the definition to a
<h3 id="cr5">Separate code list from the model to make their lifecycle management independent</h3>
Added the codelists to section [[[#controlled-vocs]]].
<p class="ednote" title="use of dct:type">
The property rrmv:hasType is not discriminating between the constraints of the domains Action Result, Role, Agent.
That makes it equivalent to the generic property dct:type.
<p/>
Proposal 1. replace rrmv:hasType with dct:type
Proposal 2: replace rrmv:hasType with 3 subproperties of dct:type.
<p/>
As long no additional constraints like additional usage constraints, such as <i> in case X, then Y must be provided</i> or cardinality constraints with a qualified usage for a specific codelist, proposal 1 is fine. However for implementers of an editorial interface Proposal 2 may be more stable and attractive.
</p>
<p class="ednote" title="URI for code in codelists">
It is recommended to manage the URIs for the codelists in a separate namespace.
Expand Down Expand Up @@ -4329,10 +4320,9 @@ <h3 id="cr7">Reduce the number of connectors and associated classes by using att
<ul>
<li> rrmv:hasTitle becomes dct:title </li>
<li> replace range xsd:string with a language aware string literal as range. </li>
<li> replace rrmv:hasTemporalEntity with rrmv:hasUnit </li>
<li> the property rrmv:hasTemporalEntity and class TemporalEntity are replaced with rrmv:hasUnit refering to a to be determined codelist</li>
</ul>
</p>
Expand All @@ -4353,8 +4343,50 @@ <h3 id="cr8">Consider “Request” as a separate entity from eli:LegalExpressio
</p>
<h3 id="cr8">Introduction of the ExecutionRequest, ExecutionAction and ExecutionActionResult </h3>
This is applied in a seperate next version to avoid interference with other changes.
This is applied in a separate next version to avoid interference with other changes.
<h3 id="cr9">New Change Requests</h3>
<h4 id="cr9a">Temporal information </h4>
In the model a Request has a frequency and an Action happens at a time.
The sentence "6 months after the directive enters into force, the MS must provide a report containing ... every two years."
In this sentence the frequency is "every two years", while "6 months after the directive enters into force" is the start date.
The question resides why this information is associated with the Action and the frequency is associated with the more conceptual entity Request.
<h4 id="cr9b">Temporal information:Frequency </h4>
The EU Vocabularies contains a codelist for <a href="https://op.europa.eu/en/web/eu-vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/frequency">frequencies</a>.
It should be considered if this codelist is not better suited to address the usecase of the class Frequency.
<h4 id="cr9c">annotations </h4>
The process of dectecting the RRMV concepts in legislation is a two step process.
The first is textual analysis in which the relevant text in the legistation is identified and associated with the RRMV concepts.
Based on this textual representation each RRMV concept is then turned into a machine readible representation.
<p/>
In the current RRMV this first phase is not universally applied. It seems as if an Agent could be determined as machine readible
information without this text analysis.
<p/>
Proposal to create a metaclass: rrmv:TextualAnalysis which intention is to capture all information to enable text to structured information transformation.
Introducing this supporting class will make the model more readible, condense and it makes abstraction of the indiviual transformation case.
E.g. The same input information is available for Actions as for Frequencies or Agents.
<p/>
Additionally the current approach applies a copying approach. Namely the identified highlighted text is stored in an annotation.
There exists an approach to have the hightlighted annotations not stored in an extracted way but as a reference in the text: <a href="https://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core/nif-core.html">NIF</a>.
<h4 id="cr9d">use of dct:type instead of own minted properties</h4>
The property rrmv:hasType is not discriminating between the constraints of the domains Action Result, Role, Agent.
That makes it equivalent to the generic property dct:type.
<p/>
Proposal 1. replace rrmv:hasType with dct:type
Proposal 2: replace rrmv:hasType with 3 subproperties of dct:type.
<p/>
As long no additional constraints like additional usage constraints, such as <i> in case X, then Y must be provided</i> or cardinality constraints with a qualified usage for a specific codelist, proposal 1 is fine. However for implementers of an editorial interface Proposal 2 may be more stable and attractive.
</p>
Expand Down
Loading

0 comments on commit 90beeb6

Please sign in to comment.