Re: [dxwg] Attribution does not cover most MARC relators and other roles (#1521)

 @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](https://w3c.github.io/dxwg/dcat/#Property:resource_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:Agent`s) 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](https://w3c.github.io/dxwg/dcat/#qualified-forms) 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](https://w3c.github.io/dxwg/dcat/#Property:resource_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. 


 


 

-- 
GitHub Notification of comment by bertvannuffelen
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1521#issuecomment-1174428191 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 4 July 2022 22:17:22 UTC