@janvoskuil I do not see that prov:Attribution "implies by definition that the attributee was directly involved in the activity that generated the entity and bore some responsibility for that activity".
The definition of prov:Attribution seems to make it explicit that it can apply when the activity is unknown or irrelevant: "Attribution is the ascribing of an entity to an agent. When an entity e is attributed to agent ag, entity e was generated by some unspecified activity that in turn was associated to agent ag. Thus, this relation is useful when the activity is not known, or irrelevant."
So, I see no implication of direct involvement or responsibility.

@makxdekkers In an attribution relation wasAttributedTo(id; e, ag, attrs), ag is "the identifier (ag) of the agent whom the entity is ascribed to, and therefore bears some responsibility for its existence" (PROV-DM).
Moreover, the activity that generated the entity is not expressed but it is implied. The implicit activity is associated with the agent of the attribution: the PROV-DM definition reads: "When an entity e is attributed to agent ag, entity e was generated by some unspecified activity that in turn was associated to agent ag". Associated with means that the agent was directly involved in the activity.

A dedicatee (MARC relator) cannot be said to be an agent to whom the entity was attributed. Same for "collector" and many, many other MARC relators. Or take 'stakeholder' (CI Role).

@janvoskuil I see your point, but there is some subjectivity there. For example, you state that "associated with -- or to as the definition says -- means direct involvement". I do not fully agree with that implication. The PROV definition keeps the activity at arms-length from the agent -- there was some activity but we may not know what it was, which is in some way which we may not know or care about, associated to the agent.
In my mind, there might be different cases: I would argue that funders, custodians and collectors do have clear roles and responsibilities associated to a resource for which attribution could be a reasonable relationship. "Dedicatee" would indeed be more of a stretch, but then, how many datasets would be dedicated to someone? So I think that some of the MARC relators could be modelled as attribution roles, but maybe not all.

Some subjectivity is involved, true --- but necessarily so, because PROV is not very much formalized. Wiggle room exists. We do know, though, that the implicit activity in an attribution was an activity that generated the entity and that was associated with (or to) the agent. The activity is, indeed, kept at arms length because it is unknown or irrelevant: agree. But the implication is clear: an attributee is a creator because they were involved as agents in (and hence responsible for) generating the entity. No example of attribution in the PROV documents or the PROV book involves a non-creator role.

A funder of a research paper or dataset is not responsible for the existence the paper or the dataset: research is generally seen as being independent of funders. Collector is defined by MARC as in [1]: explicitly not a creator. That funders and collectors have clear roles and responsibilities is not the point: they are not involved in the activity that generated the enity.

In all fairness, many MARC relators are not attributions but not involvements either --- location, or judge, for instance. However, many non-attribution roles are useful to include in metadata.

DCAT resources include other 'cataloged resources' than just datasets. In our case, we use DCAT resources (among other resources) to describe millions of documents from thousands of sources (per year). We need to create a concept scheme for roles. This will include roles like 'addressee', 'receiver', 'approver', 'commentator', 'stakeholder'.

A broader problem with attribution is that it implies agent involvement. The resource prov:Agent is a role: you are only a prov:Agent with respect to the activities that you are responsible for. Dedicatees, receivers and stakeholders are not agents with respect to an activity that is identical to or directly or indirectly connected to the generation activity.

See the article referenced above for a more detailed analysis.

[1] A curator who brings together items from various sources that are then arranged, described, and cataloged as a collection. A collector is neither the creator of the material nor a person to whom manuscripts in the collection may have been addressed (url)

@janvoskuil I really disagree with your statement: "That funders and collectors have clear roles and responsibilities is not the point: they are not involved in the activity that generated the enity". In my opinion, without the funders and collectors the dataset might not even exist. They may not be 'creators' of the material but their role, the way I see it, is certainly important enough to get attribution. But again, it's quite subjective.
Some of the distinctions we're discussing here, while they may look very important to us experts, might even be confusing for laypersons and then it may not help interoperability. For example, one metadata creator could consider a funder really important and asserts attribution, while another creator, given the option of your suggested 'involvement' property, could opt for that one -- and then references to funders can be found in two different places. That would not be good.

@lucmoreau or @pgroth can probably enlighten us. Is it abusing prov:Attribution to use it for denoting funders, collectors, or other agents that are not as directly involved in the creation of a resource?

PROV is a very high level model. It recognises the following upper classes

• Entity (Thing, Endurant, Continuant)
• Activity (Process, Perdurant, Occurrent)
• Agent (a special kind of Entity)

These have the following standard relationships between them

• attribution - between Entity-Agent
• association - between Activity-Agent
• generation - from Entity-Activity
• use - from Activity-Entity

That's essentially it. There are some elaborations, mostly involving association classes, but those terms are intended to encompass all the potential detailed relationships involving those pairs of classes. In particular, prov:Attribution should not be understood as equivalent to "h-index attribution" (etc), which is only a sub-set. prov:Attribution is scoped to PROV.

I think the most important point here is the distinction between agent --- which PROV defines as a (non-rigid) role concept --- and entity. Some roles in CI Roles, MARC and other role taxonomies qualify as agent roles (creator, collector, funder), whereas others qualify as usages (addressee, recipient, dedicatee). In some cases, it can go either way, depending on the specifics of each individual case (stakeholder).

I totally agree with Makx's point that people responsible for assigning metadata should not have to understand all these finer distinctions. They shouldn't have to choose, because in practice, different people will make different choices in similar situations, leading to a loss of generality. Therefore, to accommodate the incorporation of said role taxonomies in a metadata scheme based on DCAT and PROV, it would be useful to be able to use a generic relation that expressly abstracts away from all these and related distinctions. This will be a relation between arbitrary entities and entities that can bear responsibility, i.e., instances of prov:Entity and of prov:Agent that are also instances of foaf:Agent. Or, simply put, a relation between instances of prov:Entity and instances of foaf:Agent.

Making it necessary to choose different relations for different role concepts in MARC etc introduces semantic redundancy and is a source of confusion.

@janvoskuil Would dct:relation be sufficient for such a generic relation?

Yes, I think so, but it would need to be part of an L2-relation because we have the entity, the foaf:Agent (prov:agent or 'volitional entity'), and the concept.

dcat:Relationship (with dct:relation) could be generalized. There is a strong intuitive difference, though, between "translation of" en "version of" on the one hand (which are typical dcat:Relationships, between entities and 'non-volitional entities'), and relations like "recipient", "stakeholder".

Perhaps we could use dct:relation in the context of dcat:Relationship to cover both cases, and let the concept do its work. Users could use different concept schemes or a concept hierarchy to indicate the difference more clearly. Alternatively, or in addition, there could be two subproperties, say, 'relatedObject' for "translationOf" and 'relatedAgent' for "adressee" (with 'agent' in the foaf-sense).

This would perhaps be the most elegant solution. It would generalize the definition of dcat:Relationship from "An association class for attaching additional information to a relationship between DCAT Resources" to something like "... a relationship between a DCAT resource and another resource, such as a foaf:Agent or another DCAT resource". Also, the superclass would then be prov:Influence rather than "Entity influence".

dct:relation is "A related resource." I don't see that as including agents because of how "resource" is used in the DC Terms vocabulary.

dct:Agent is defined as "A resource that acts or has the power to act." I normally tend to interpret the word "resource" as in RDF, i.e., a thing. It is true, though, that all DCMI-defined subproperties of dct:relation are entity-entity or entity-entity-ish relations, see [1]. If dct:relation is deemed to be specific for entity-entity relations, then a generalized form of dcat:Relationship could take a different property to link instances of dcat:Relationship to instances of foaf:Agent (or dct:Agent, which seems to be very similar). Perhaps something like "dcat:party". Or perhaps "dcat:agent", though not prov:agent because that would only select foaf:Agents that are responsible for the entity's existence, or, more accurately, that have an agentive, volitional involvement in the entity --- excluding cases like addressee, recipient, dedicatee, etc.

[1]
dct:conformsTo, dct:hasFormat, dct:hasVersion, dct:hasPart, dct:isFormatOf, dcterms:isPartOf, dct:isReferencedBy, dct:isReplacedBy, dct:isRequiredBy, dct:isVersionOf, dct:references, dct:replaces, dct:requires

dct:relation is "A related resource." I don't see that as including agents because of how "resource" is used in the DC Terms vocabulary.

@kcoyle As far as I understand RDF modelling, the moment you describe a person with RDF assertions, the persons 'becomes' an RDF resource. So in my mind, you should be able to assert dct:relation between something and an Agent, and even between two Agents.

I tried to follow the dicussion here, but I somehow lost track. And upfront my apologies for the extensive comment.

Note that already dct:relation is part of DCAT ( https://w3c.github.io/dxwg/dcat/#Property:resource_relation) as a generic relationship between two Catalog Resources.
And that [prov:qualifiedAttribution with range prov:Attribution (https://w3c.github.io/dxwg/dcat/#Property:resource_qualified_attribution) was introduced as a generic property to indicate a relationship between Catalog Resources and Agents.

That is the mapping choice that has been made. If we are going to apply dct:relation also for the second case then what is the difference between them? I would even drop dct:relation at all, because then it becomes the universal property in DCAT that relates anything with anything. So what is the added value to add this to DCAT then?

Changing the semantics of the terms "qualifiedRelation" and "qualifiedAttribution" because the mapping on prov-O is incorrect is not a good idea: then one should introduce a new property dcat:qualifiedAttribution.
The consequence of this might be even that one should refrain from using prov-O at all in DCAT. Because if one mapping is incorrect, then likely also the others are, and thus DCAT becomes incompatible with prov-O.
If this is the conclusion from the issue, I rather have that explicitly stated then trying to create complex structures that would allow prov-O to match DCAT.

The next paragraphs are a longer exposé trying to understand the issue in my words.

Then on the argument that the reuse of prov-O in the DCAT context is incorrect or inappropriate.
I cannot pinpoint the issue, but one should question if this reuse mapping is coherent with the generic prov-O. Is the DCAT usage a specific profile usage of prov-O. In that case there is no problem: because then DCAT is semantically a specialisation of prov-O.
Assuming this is the case, the question might be what are the examples you point out in your study.
Here it might become tricky, because I might not understand the subtleties you are pointing out, but to me the MARC list seems to be a fine code list for dcat:hadRole.

I do, however, believe that in the main target usage case area of DCAT, woodcutter is not a role people have in mind.
And then I come to the applicability and the use cases for DCAT.
For me, personally, is, although DCAT provides a generic framework for a catalogue of Catalogues, the main usecase sharing catalogues of datasets.
I do not expect to find in e.g. data.europa.eu wooden puppets in medieval Turkey (catalog resource descriptions for each puppet). I only expect to find a single entry: namely a dataset that contains the descriptions of all the wooden puppets.
If your usecase is situated in the wider usecases, then it is to be expected that the narrow interpretation might not match your usecase.
It might be that your planned usage of DCAT as the prime vocabulary is not fitting your usecase. If provenance is key to your challenge, then maybe building your own prov-O profile might be the answer instead of adapting DCAT.
So maybe the issue raised by you might be because this scope mismatch. Understanding that might lead to a better understanding of discussion that triggered this issue.

One remark in the whole thread also struck me: you make explicit distinction between foaf:Agent and prov:Agent as disjoint classes. I never made that, and never felt the need for that. And maybe also that is an indication of the issue that you are raising: in the core DCAT usage context most implementers would not make (or like to make) a distinction. What if DCAT would assume these are synonyms? What would be the impact?

An additional thought in this area: it seems that this discussion forgets there is underlying DCAT the Semantic Web. This means that one can extend the specification at will, but that the extensions might not be understood by others. For me there is no difference between having marc:woodcutter as subproperty of dct:relation or marc:woodcutter as role in qualifiedAttribution. Both are equally not understood by DCAT processors.
DCAT processors will know there is a relation between 2 entities and that is it. Why is that: because the controlled vocabulary of roles is not fixed. It is left to the profile. So in order to understand marc:woodcutter the DCAT processor needs to understand the profile.
Even more, the first option is the preferred option by DCAT: In the usage note of https://w3c.github.io/dxwg/dcat/#Property:resource_relation states that the subproperties of dcterms take precedence of any qualified relation.
Why not writing the same for qualifiedAttribution?

The above actually means that the qualifiedRelation and qualifiedAttribution as generic pattern actually are builtin the RDF Semantic Web language.
For me, the explicit statement of the triple <A> dct:relation <B> is semantically equivalent with <A> p:dummy <B> as dct:relation is stating there is some relationship, but not further detailed between <A> and <B>.
So even you do not know the meaning of p:dummy you know there is a relationship, thus you can infer from the second the first.
This line of thought brings us then to a discussion about abstraction and scope: what are the relationships one likes to abstract away between <A> and <B>.
Here in DCAT the usage of dct:relation is restricted to relationships where <A> and <B> are dcat:Resource.
So not any property but only those, and even more, specifically, not those for which we have an explicit name for in the DCAT specification. So to indicate the relationship between a Catalog and a Dataset one uses dcat:dataset instead of dct;relation.
The usage of dct:relation is thus restricted to add DCAT processors with all the extensions profiles make: the relationship should be maintained at least on this abstract level.
However note that is it not incorrect to use dct:relation between a Catalog and a Dataset to indicate a membership, but one cannot expect that a DCAT processor will interpret the dct:relation as such.

My point is that the above prov-O analysis might be non-existing topic as the usage of qualifiedRelation and qualifiedAttribution is not required to achieve the objectives of expandability, and semantical clarity of relationships between entities. The Semantic Web already offers that.
So even if the prov-O interpretation for DCAT qualifiedAttribution is only covering 10% of the prov-O potential, then it is fine for me. It is a restrictive usage like the dct:relation mapping in DCAT.
In the end it is the capability of the DCAT processor to handle profiles that determines the handling of these properties/roles and that is beyond the scope of DCAT itselves.

dct:relation is "A related resource." I don't see that as including agents because of how "resource" is used in the DC Terms vocabulary.

@kcoyle As far as I understand RDF modelling, the moment you describe a person with RDF assertions, the persons 'becomes' an RDF resource. So in my mind, you should be able to assert dct:relation between something and an Agent, and even between two Agents.

@makxdekkers are we discussion dct:relation or the DCAT notion relation ?
That are 2 different things for me.

In my extensive comment I already mentioned it. The DCAT community has introduced for the semantic notion of relating 2 resources the property relation (https://w3c.github.io/dxwg/dcat/#Property:resource_relation) and mapped it on dct:relation.
So the use of dct:relation in any RDF exchange of a DCAT catalogue should be restricted to the semantics expressed in this property.

Any broader usage allowed by dct:relation is out of scope for DCAT. Fine when reading it with dcterms glasses, but not for DCAT. Within DCAT dct:relation has a restricted meaning.

Note that this reasoning holds for every DCAT term that is mapped on an URI that is not within the DCAT domain. That is the nature of reuse.

So while I agree that dct:relation could be used to relate a DCAT Resource with an Agent, it has been chosen to use dct:relation for inter DCAT Resource relationships. And to use another property for the Resource - Agent relationship.
Personally I find it natural to separate these 2 cases, despite (abstract) knowledge pattern wise there will be in handling them no difference.

But we have to be modest and realise that whatever choice is made here will not make the life of an implementer easier. It will be up to the implementers to make sense out of it, as any modeling choice, even guided by the current DCAT, is very open. In this area, DCAT could also decide to not interfere and only provide the guideline: this is profile matter. The usage note is almost stating it.

Let me recapitulate.

The problem

The original problem is that DCAT offers no way to express relations between resources and agents (in the sense of volitional things such as persons and organizations) when the agent bears no responsibility for the existence of the resource.

prov:Attribution only covers the subset of resource-agent relations where the agent "bears some responsibility for the existence of the resource", like author and creator, but excluding cases like dedicatee, addressee, recipient. These latter cases are typically relations that we need to cover in our use cases, where we need to describe government documents and their relations (to put it simply). The problem is not that we cannot figure out a way to capture these cases, the problem is that we would like to do it, for obvious reasons, in a way that uses DCAT vocabulary.

Independent problems in the background

In the background of this original problem there are many (indirectly) related problems that can and should be put aside to keep the discussion focussed.

One problem is that prov:Agent is defined as a relational entity, a role. You are only a prov:Agent with respect to the activities you bear some responsibility for. To define organization and person as subclasses of this is obviously wrong but a very common mistake in upper ontologies, as is well-known in the formal ontology community. This causes a lot of confusion. But the original problem has a clear scope and can be solved independently of the prov:Agent-problem.

Another problem in the background is where to draw the line exactly between being and not being responsible for the existence of an entity. Personally, I would include painter but not collector (of a painting), but then there are others who argue that inclusion of collectorship is totally in the spirit of prov:Attribution. Nobody seems to argue, though, that dedicatee, addressee, recipient, stakeholder, and many other such relations can meaningfully be included.

Proposed solution 1

The best solution seems to define a new L2 DCAT relation that covers all and only resource-agent relations, called dcat:Involvement. The property relating resources to instances of this relation would be dcat:qualifiedInvolvement. The property relating instances of this relation to agents (volitional things, foaf:Agents) would be dcat:involved. This solution is the exact parallel of dcat:Relationship.

Then, prov:Attribution is the subset of those dcat:Involvement relations where the agent is responsible for existence of the resource. The general preference that says 'be as specific as is feasible' would be relevant here. Different people will make slightly different choices about the exact delineation of attribution, but that is independent of this solution (they will do so anyway). Other people may choose to use dcat:Involvement in all cases because, for them, making the distinction is too expensive.

This solution is elegant because it does not change existing notions and has minimal impact. A clarifying note can explain very briefly and clearly why dcat:Involvement is needed.

Proposed solution 2

Another solution would be to generalize the notion of dcat:Relationship to include resource-agent relations alongside resource-resource relations. This changes the semantics of an existing DCAT notion, and there are additional complications in the choice of properties to use.

As in Proposed solution 1, prov:Attribution would be a subset of this generalized class, selecting those relations where the agent is responsible for existence. A choice that needs to be made in this solution is which property to use to relate instances of dcat:Relationship to agents.

Option 1
Use dct:relation for all cases. As @kcoyle remarked, this may be outside existing conventions of using this property, but it would be consistent with its normative definition.

Option 2
Use dct:relation for resource-resource relations, and a new property, say, dcat:involved, for resource-agent relations.

Given this complication, I think that I would prefer Proposed solution 1.

'Party' is sometimes used as a superclass of Person and Organization.
A Party may then have agency in relation to some activity, and may have responsibility in relation to some entity.

However, it will be hard to get the nomenclature in PROV changed.

@janvoskuil

thanks for the summary.

Let me recapitulate.

The problem

The original problem is that DCAT offers no way to express relations between resources and agents (in the sense of volitional things such as persons and organizations) when the agent bears no responsibility for the existence of the resource.

prov:Attribution only covers the subset of resource-agent relations where the agent "bears some responsibility for the existence of the resource", like author and creator, but excluding cases like dedicatee, addressee, recipient. These latter cases are typically relations that we need to cover in our use cases, where we need to describe government documents and their relations (to put it simply). The problem is not that we cannot figure out a way to capture these cases, the problem is that we would like to do it, for obvious reasons, in a way that uses DCAT vocabulary.

Independent problems in the background

In the background of this original problem there are many (indirectly) related problems that can and should be put aside to keep the discussion focussed.

One problem is that prov:Agent is defined as a relational entity, a role. You are only a prov:Agent with respect to the activities you bear some responsibility for. To define organization and person as subclasses of this is obviously wrong but a very common mistake in upper ontologies, as is well-known in the formal ontology community. This causes a lot of confusion. But the original problem has a clear scope and can be solved independently of the prov:Agent-problem.

Another problem in the background is where to draw the line exactly between being and not being responsible for the existence of an entity. Personally, I would include painter but not collector (of a painting), but then there are others who argue that inclusion of collectorship is totally in the spirit of prov:Attribution. Nobody seems to argue, though, that dedicatee, addressee, recipient, stakeholder, and many other such relations can meaningfully be included.

I am not going to argue about the correctness of the above analysis,
but if I am correct: your request is to change the definition for qualified attribution from

Link to an Agent having some form of responsibility for the resource

to

Link to an Agent

Removing the additional restrictive scoping of responsibility.
And as a consequence also replace the mapping from prov:Attribution to something else (below).

Then the DCAT community should answer the question: "what was the motivation to solely include responsability roles?".

Proposed solution 1

The best solution seems to define a new L2 DCAT relation that covers all and only resource-agent relations, called dcat:Involvement. The property relating resources to instances of this relation would be dcat:qualifiedInvolvement. The property relating instances of this relation to agents (volitional things, foaf:Agents) would be dcat:involved. This solution is the exact parallel of dcat:Relationship.

Then, prov:Attribution is the subset of those dcat:Involvement relations where the agent is responsible for existence of the resource. The general preference that says 'be as specific as is feasible' would be relevant here. Different people will make slightly different choices about the exact delineation of attribution, but that is independent of this solution (they will do so anyway). Other people may choose to use dcat:Involvement in all cases because, for them, making the distinction is too expensive.

This solution is elegant because it does not change existing notions and has minimal impact. A clarifying note can explain very briefly and clearly why dcat:Involvement is needed.

Proposed solution 2

Another solution would be to generalize the notion of dcat:Relationship to include resource-agent relations alongside resource-resource relations. This changes the semantics of an existing DCAT notion, and there are additional complications in the choice of properties to use.

As in Proposed solution 1, prov:Attribution would be a subset of this generalized class, selecting those relations where the agent is responsible for existence. A choice that needs to be made in this solution is which property to use to relate instances of dcat:Relationship to agents.

Option 1 Use dct:relation for all cases. As @kcoyle remarked, this may be outside existing conventions of using this property, but it would be consistent with its normative definition.

Option 2 Use dct:relation for resource-resource relations, and a new property, say, dcat:involved, for resource-agent relations.

my assessment of the options:

option 1)

I object to just change the mapping for qualified attribution as suggested in option 1 as it will coincide with the semantics of https://w3c.github.io/dxwg/dcat/#Property:resource_relation
According to the current DCAT the following is inconsistent, while in the future it would be consistent:

ex:d1
  dcterms:relation ex:d2  ;
  dcterms:relation ex:agentRole1 .

ex:agentRole1 
   dcat:hadRole ex:role1;
   prov:agent/dct:relation ex:agent1.

We should not introduce ambiguity between the RDF representation (2 expectations for the same URI) in the specification.
I mean: each RDF property should be mapped on 1 of the definitions in the DCAT specification, and there should be no 2 options.

If with option 1 you mean

• remove qualified_attribution
• remove qualified_relationship
• remove relation
• add dct:relation for all Resource -> whatever entity
• add new qualified_relation for all Resource -> dcat:Relationship -> whatever entity

Then option 1 is possible, that is coherent for the DCAT spec, but it is a substantial rewrite of the specification.

option 2)
feasible, but I agree if it is the desirable way to go

For me there are also the following options:

option 3)
- remove relation
- remove qualified_relationship
- remove qualified_attribution
but maintain the section 15 and rely on profile building.

As I tried to explain: the semantic value of these relationships at the DCAT level is very very limited.
All knowledge is in the profile: which role/relation to use for which case and with which values.
So by DCAT being a Semantic Web vocabulary the 3 above cases are already part of the story, they are thus redundant.
In my opinion even the "standardized role pattern" is limited actual semantic value, because it is so abstract.

option 4)

• no change at all

and the answer to your use case is: this is part of the profile you are building. DCAT could make this explicit in a usage note and state that DCAT only focuses on roles with responsibility aspects.

option 5)

• change definition for qualified attribution to
  Link to an Agent. and maintain the mapping on prov:Attribution.

The definition of prov:Attribution is Attribution is the ascribing of an entity to an agent. When an entity e is attributed to agent ag, entity e was generated by some unspecified activity that in turn was associated to agent ag. Thus, this relation is useful when the activity is not known, or irrelevant. So if you very permissively read generated by and unspecified activity
then is becomes broader.

conclusion
Whatever option is taken: you will not escape from profile building. Thus to progress your use case, my advice would be to apply option 2 in your namespace and you have dealt the use case in a DCAT conform approach.

From the five options my preference goes to option 3), because it removes this abstract discussion from DCAT as it is anyhow profile matter for me, or option 5) a minimal impact change.

Thanks @bertvannuffelen for your thoughts.

I am not going to argue about the correctness of the above analysis, but if I am correct: your request is to change the definition for qualified attribution from

Link to an Agent having some form of responsibility for the resource

to

Link to an Agent

Removing the additional restrictive scoping of responsibility. And as a consequence also replace the mapping from prov:Attribution to something else (below).

Then the DCAT community should answer the question: "what was the motivation to solely include responsability roles?".

To be precise, what I propose is that DCAT includes vocabulary to express resource-agent relations in which the agent does not bear responsibility for (an implicit or explicit activity that lead to) the existence of the resource. Concretely, this would include relations like dedicatee, addressee and recipient.
Example:

x:novel123
  a x:ContentItem, dcat:Resource ;
  dcat:qualifiedInvolvement x:i_0ae58f ;
.
x:i_0ae58f
  a dcat:Involvement ;
  dcat:involved x:agent42 ;
  dcat:hadRole x:dedicatee ;
.
x:agent42
  a foaf:Agent ;
  x:name "Susan Roe" ;
.

As for the question "what was the motivation to solely include responsability roles?", I think the answer is oversight. The DCAT documentation advertises prov:Attribution as a way to express entity-agent relations like those included in MARC and other sources. However, because of the PROV-definition, many of those relations cannot be expressed with prov:Attribution. This is not immediately obvious; it involves close-reading the PROV-documentation. I do not think it can be expected that PROV will change this, as it would impact PROV at its core. This leaves a gap, because, as the DCAT documentation states, it is useful to include relations such as the MARC relators in general.

I agree that application profiles remain important in all cases. However, this is not about adding detail and restrictions to generic DCAT vocabulary, it is about filling a gap. Moreover, it is a gap that can easily lead people to misuse prov:Attribution. One could argue that this is PROV's problem, not DCAT's, but the higher goal is FAIR descriptions of catalogued items.

As for @dr-shorthair's suggestion to use the term party: I like this suggestion but I have second thoughts because 'party' has, in English, the exact same ambiguity as 'agent': it can be used as a relational term ("A and B are parties to this contract"). A term like 'volitional being' would be less prone to relational readings. I think that, in the end, it is best to stick to foaf:Agent.

Project/Milestone modified.

Explanation: As DCAT v3 moves through review and hopefully ratification, we want to make sure that open issues and feedback that have yet to be completely addressed are properly recorded and tagged/assigned in github to both clarify their status and to help review and prioritise as a source of improvements and new requirements in future DCAT versions