RE: Extending hadRole to Attribution


Interesting discussion as I have also faced similar need for ‘role shortcuts’. My rants below:


I agree that the PROV examples should not use ex:hadRole as a lazy shortcut as it can be confusing.


My take:

In OWL prov:hadRole can be used with any prov:Influence that is either an prov:Association or a prov:InstantaneousEvent (union).
https://www.w3.org/TR/prov-o/#hadRole



prov:Attribution is a subclass of prov:AgentInfluence which is subclass of prov:Influence.

https://www.w3.org/TR/prov-o/#AgentInfluence actually list prov:hadRole – while this might be an artefact of how that HTML was created from the OWL, you would be in the clear here from a pure textual reading of the PROV-O spec.


Outside the OWL2-RL profile (e.g. in RDFS) prov:hadRole can be used with any prov:Influence, so here you would also be in the clear, however this was intended more of a workaround when unions are not supported:
https://www.w3.org/TR/prov-o/#owl-profile



Assuming OWL, it might sound strange to say an Attribution is an InstantaneousEvent as you would normally contribute to (the generation of) an entity over a period of time (aka an Activity).  But if a Generation event Is when the entity is ‘ready’ then an Attribution-as-an-event would be when the agent first touches (what will become) the Entity. As such the prov:atTime here must necessarily be the same time or before the Generation prov:atTime. (the agent can’t influence the entity after it has been made).

To make this clear you can either make a subclass/instance of both Attribution and InstantaneousEvent; or add prov:atTime to the Attribution – ensuring that the time is the same or before the generation time.


It would not make sense to make the Attribution also be a Generation, as that implies there is only a single creator making the entity at once – but then you don’t need prov:hadRole.



https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#term-attribute-role defines the prov:role attribute as
A role ◊<https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#concept-role> is the function of an entity or agent with respect to an activity, in the context of a usage<https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#concept-usage>, generation<https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#concept-generation>, invalidation<https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#concept-invalidation>, association<https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#concept-association>, start<https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#concept-start>, and end<https://www.w3.org/TR/2013/REC-prov-dm-20130430/Overview.html#concept-end>.


So while technically you can use prov:hadRole with a prov:Attribution in PROV-O  (keeping in mind the time ordering implications), that may not be recognized by the other PROV serializations in the same way as on Usage/Generation/Invalidation/Association/Start/End.

In PROV-DM prov:role (note, not hadRole) is just a free-standing attribute, and the there are generally not any restrictions on which attributes can be used in non-RDF serliaizatoins of PROV.

Lower-case prov:role is defined in the namespace document http://www.w3.org/ns/prov#role – but not in the PROV-O ontologies. If you were to use lower-case prov:role that is defined within the prov# namespace, but if you are doing OWL, I would use it as an AnnotationProperty to avoid any OWL inferences. It might also cause a bit of confusion.

prov:Role as a class on the other hand is not constrained in any, so it would be perfectly fine for a new property to use it in its domain, or for new subclasses to be defined. https://www.w3.org/ns/prov.ttl  already have prov:Contributor, prov:Publisher, prov:RightsHolder from PROV-DC as you point out.


Some agent roles for entities are not restricted to helping with its generation, as you point out – for instance a support agent or curator will be in the present/future rather than in the past. The RightsHolder might also legally change after the entity was made/published. In non-scruffy provenance it would be wrong to model these as some kind of prov:Influence on a pre-existing Entity.  Describing general attributes of an entity that is not related to its history is outside of the scope of PROV, even if this would be a Entity-Agent association.


Similarly there could be  Agent/Activity associations that are not in scope for prov:Association as they do not influence the activity:

:fifaworldcup2018 a prov:Activity .

:me a prov:Agent, prov:Person ;
      :wantsToPlayIn :fifaworldcup2018.



--
Stian Soiland-Reyes, eScience Lab
School of Computer Science, The University of Manchester
http://orcid.org/0000-0001-9842-9718


From: Car, Nicholas (L&W, Dutton Park)<mailto:Nicholas.Car@csiro.au>
Sent: 25 June 2018 14:20
To: Moreau, Luc<mailto:luc.moreau@kcl.ac.uk>; public-prov-comments@w3.org<mailto:public-prov-comments@w3.org>
Subject: Re: Extending hadRole to Attribution

Hi Luc,

So far we’ve understood that inferencing so have modelled things like this (https://github.com/w3c/dxwg/issues/79#issuecomment-399668872):

:Dataset_X a prov:Entity ;
  prov:wasAttributedTo :Agent_Y ;
  prov:wasGeneratedBy [
    a prov:Activity, prov:Publish ; #’Publish’ taken from PROV-DC
    prov:wasAssociatedWith :Agent_Y ;
      prov:qualifiedAssociation [
        a prov:Association ;
        prov:agent :Agent_Y ;
        prov:hadRole [a prov:Publisher] . #’Publisher’ as per from PROV-DC
      ] .
  ] .

I dp see the point: an Activity can only ever have one causative Agent involved but an Agent related to an Entity is not restricted to one Agent (viz.  “influencer” or “influencee”). So the PROV solution, if an Agent/Entity relationship does need a Role somewhere, is to make what the Agent is doing explicit by inferring the Activity, as with Publish above, and then associate the role to the Agent in relation to the Activity.

We can live with that I suppose, but pity about the confusing ex:hadRole examples in PROV-O though…

What we might do is to come up with some other construct that’s not a PROV-style Role but is exactly the more time-eternal Entity/Agent thing we see commonly used for Dataset/Agent relations in other metadata models, such as ISO19115 (Geographic Metadata) where a Dataset (Entity) can have a citedResponsibleParty with a RoleCode like “owner”. The main purpose is to be able to use code lists instead of Dublin Core-style named properties like dct:publisher, dct:creator etc.

See you in a couple of weeks at IPAW no doubt.

Cheers,

Nick

From: "Moreau, Luc" <luc.moreau@kcl.ac.uk>
Date: Monday, 25 June 2018 at 6:30 pm
To: Nicholas Car <Nicholas.Car@csiro.au>, "public-prov-comments@w3.org" <public-prov-comments@w3.org>
Subject: Re: Extending hadRole to Attribution


Hi Nick,

We defined role as  (https://www.w3.org/TR/prov-dm/#concept-role)
“A role is the function of an entity or agent with respect to an activity”.

At the time, my recollection was that it was useful to specify a role in the context of an activity.  Attribution, as you mention it, does not have an activity. That’s why it was not included.

I wouldn’t have any objection with supporting roles for attribution, but this has some implications:

  *   Need to change the definition of role. What is it?
  *   Who is the role associated with? Is it the “influencer” or “influencee”? In your example, it looks like the “influencer”, but we could imagine roles for “influencees” too?  If it’s the case, we are back to the problem we faced in the WG: complex naming (hadInfluencerRole/hadInfluenceeRole) with the further problem that role in Usage/Generation is related to Influencer/Influencee respectively.

This said, in PROV with
https://www.w3.org/TR/prov-constraints/#attribution-inference, you have the possibility of associating a role to your agent in the association. What PROV does not allow us to do is link explicitly Attribution and the corresponding activity.

Regards,
Luc



--
Professor Luc Moreau,  Head of Department
Department of Informatics, King’s College London
Strand Campus, Bush House, 30 Aldwych, London, WC2B 4BG.
Tel: +44 207 848 6808, web: https://nms.kcl.ac.uk/luc.moreau/





From: "Car, Nicholas (L&W, Dutton Park)" <Nicholas.Car@csiro.au>
Date: Monday, 25 June 2018 at 09:11
To: "public-prov-comments@w3.org" <public-prov-comments@w3.org>
Subject: Extending hadRole to Attribution
Resent-From: <public-prov-comments@w3.org>
Resent-Date: Monday, 25 June 2018 at 09:10

Dear PROV people,

We are finding it unhelpful to have to implement a very similar property to prov:hadRole to model Entity/Agent relationships in the Data Exchange WG due to prov:hadRole’s domain restrictions.

In the reasoning for setting the domain for prov:hadRole to prov:Association (see [1]), the PROV WG indicated that there was this restriction, rather than allowing “roles for all relations”, due to a permissive approach potentially leading to confusion over who is playing what role. I understand the potential when there are multiple Agents involved, as per [1] in Delegation but this is not the case for Attribution. In the same way that there is no confusion over role here (from PROV-O [2]) in Association:

:illustrating
    …
    prov:qualifiedAssociation [
        a prov:Association;
        prov:agent   :derek;
        prov:hadRole :illustrationist;
    ];
    …
.

There would also be no confusion here in Attribution (from PROV-O [3]) if the ex:hadRole was, instead, prov:hadRole:


:nationalRegionsList

   a prov:Entity;

   prov:qualifiedAttribution [

      a prov:Attribution;

      prov:agent :civil_action_group;

      ex:hadRole :owner;

   ]

.

The role here can only have been played by one prov:Agent, the :civil_action_group.

Can anyone refute this reasoning or is there an deeper issue due to Agent/Entity non-disjointness? If not, can we use consider extending the domain of prov:hadRole to also include Attribution? This would make like much easier in DXWG.

Thanks,

Nick


[1] https://www.w3.org/2011/prov/wiki/index.php?title=ResponsesToPublicComments&mobileaction=toggle_view_desktop#ISSUE-532_.28Role.29<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2011%2Fprov%2Fwiki%2Findex.php%3Ftitle%3DResponsesToPublicComments%26mobileaction%3Dtoggle_view_desktop%23ISSUE-532_.28Role.29&data=01%7C01%7Cluc.moreau%40kcl.ac.uk%7C7e3c62c1feee43d6300b08d5da733112%7C8370cf1416f34c16b83c724071654356%7C0&sdata=%2BMdxBTUb6MD33mzp1EypdN8j9zMLWVAB18nhrc06B2A%3D&reserved=0>
[2] https://www.w3.org/TR/prov-o/#Association<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fprov-o%2F%23Association&data=01%7C01%7Cluc.moreau%40kcl.ac.uk%7C7e3c62c1feee43d6300b08d5da733112%7C8370cf1416f34c16b83c724071654356%7C0&sdata=sX%2Fln%2BENvK1%2FZsTg03UlO%2Bzn%2FyvV%2Btk%2B4gTBEwzyXF4%3D&reserved=0>
[3] https://www.w3.org/TR/prov-o/#qualifiedAttribution<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fprov-o%2F%23qualifiedAttribution&data=01%7C01%7Cluc.moreau%40kcl.ac.uk%7C7e3c62c1feee43d6300b08d5da733112%7C8370cf1416f34c16b83c724071654356%7C0&sdata=pP9JzYF4HzkW10sXquXRY4JayJucjH9HOpZXhRlmo24%3D&reserved=0>


Nicholas Car
Senior Experimental Scientist
CSIRO Land & Water
41 Boggo Road, Dutton Park, QLD 4102, Australia
E nicholas.car@csiro.au<mailto:nicholas.car@csiro.au> M 0477 560 177 P 07 3833 5632

Received on Tuesday, 26 June 2018 11:06:35 UTC