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

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. 
  






 





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


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

Received on Thursday, 23 June 2022 21:34:09 UTC