Comments and remarks

General remarks

The idea is rather sketched very roughly and its rationale is not consistent with the description. I would appreciate if more examples are given. From the text presented it is hard to understand the expected meaning of properties like isRelatedTo or classes like Status (e.g. postponed or reiterated).

The example selected (a review every five years addressing very specific financial area) would not justify any work at all.  The quoted text of the Regulation 2026/1011 is incomplete, the first part is missing, and it is not clear WHO is actually responsible for the review. In fact this is the European Commission – and I am pretty sure that the responsible unit of EC would not forget about this obligation. I would rather see some examples in line with the context description, related to obligations for SME, local administration or other similar actors, with more complicated timeline (activated, suspended etc.).

The most important attribute of a Request would be its Topic, since it defines the actual scope of any reporting. RRMV would make sense only if one can easily find all obligations related e.g. to a particular area of business activity or some environmental issue. The solution adopted (just skos:Concept) is too general and is not addressing the issue at all. If for any Topic there would be a separate individual entry, this would probably be useless. The authors give no example nor any suggestion for that, although they provided separate classes for ResultType or RoleType. A similar structure of Topic seems necessary, maybe somehow related to Eurovoc with textual annotation. This would be more clear if some real life examples are given.

Technical problems and errors

Names of properties are inconsistent with ELI; ELI names use underscore character (e.g. should be has_document and has_agent_role instead of hasDocument and hasAgentRole).

A specific subproperty of dcterms:isPartOf should be used between Request and Expression. In general, in ELI no generic dcterms properties are used. In ELI 1.4 two subproperties of dcterms:isPartOf are already used, both on the Work – Work level: is_part_of (physical inclusion) and is_member_of (logical inclusion). I suggest defining a subproperty follows_from. The range of this property should include Work rather than Expression (or may be both). In most cases different Expressions differ only in their language, and reporting requirements remain the same. There is no reason to define separate Requests for every language (unless indeed this is the case, thus I suggest using both Work and Expression). It is not clear from the description, whether the property should address an act as a whole or one of its subdivisions (they are both Works). 

The use of eli:changes from Request to Request is doubtful. In ELI this property connects the act (or part of it) that somehow modifies a source with this source. In RRMV it should rather connect Work (act or part of it) that changes a request with this request. In fact, in ELI there is no property connecting old and new version of a subdivision, even in the drafted ELI-I standard (ELI Impact).

I suggest that there is a property atTime (or rather at_time) from Status to PeriodOfTime, same as for AgentRole. Maybe I do not understand, but there would be cases, where status changes over time (e.g. active to suspended to postponed to completed). Some examples would clarify that.

Errors and inconsistencies between RDF, the graph and ELI ontology:

• properties is_realized_by and is_embodied_by have wrong direction; according to the ELI ontology is_realized_by has domain Work and range Expression, is_embodied_by has domain Expression and range Manifestation;
• there is no need for hasURI property – most of classes in ELI have their URIs (in particular every Work, Expression an Manifestation);
• property hasFunction in RDF is from Action to PeriodOfTime, whereas it should be from PeriodOfTime to Function (as is in the graph);
• property hasType in RDF lacks range RoleType (present in the graph);
• property isClassifiedAs is missing in the graph;
• class Function is named TemporaryFunction in the graph (I realize that this is a label, but it is not clear, why just in this case the names in RDF and in the graph differ);
• properties duration, endtime and starttime (from PeriodOfTime) are missing in the graph, together with classes dateTime, gYear and gYearMonth;
• property starttime in RDF is misspelled (stattime);
• string property type from ActionResult is missing in the graph;
• lists of individuals differ:
  • ResultType: in RDF: action, framework, meeting, in the graph reportInProgress, actionResult
  • Status: in RDF active, partiallyArchived, if the graph activated, duplicated
  • Frequency: no individuals in the graph, but that can be on purpose (defined in code.europa.eu).