Re: [regrep] Re: [Proposed Resolution] Re: [regrep-comment] PublicComment

Farrukh Najmi wrote:

>> Farrukh,
>>
>> Yes, so one approach is to shuffle things about a bit to also include
>> AuditableEvent in Section 5 in order to better reflect the meaning of
>> provenance, which under any definition emphasizes lineage or change
>> history (i.e. the audit trail, or some part thereof).
>>
>> Possible resolutions:
>>
>> (1) Relocate the description of AuditableEvent from 7.1 to 5.x
>>
>> (2) Leave AuditableEvent where it is and substitute "Responsible
>>     Party" for "Provenance" in section 5.
>>
>>
> Hi Richard,
> 
> The AuditableEvents certainly play a role in establishing who submitted 
> an object or otherwsie changed it. However, they are the underlying 
> mechanism
> and do not on their own describe the entity that did so. They describe 
> the event not the actor that caused the event. AuditavleEvent (as the 
> name indicates)
> fits better in the "Event Information Model" chapter. That is why I do 
> not agree with proposed solution (1) above.
> 
> Proposed solution (2) just does not seem right beacuse (as I pointed out 
> earlier) that does not capture/describe all other types of provenance 
> relationship besides
> "Responsible Party".
> 
> Respectfully, I do not think it would improve our specs to do either (1) 
> or (2) and feel that the current description is best given all the 
> considerations.
> 


Yes, a naked chain of AuditableEvents by itself is insufficient to
establish provenance. But each event must refer to the relevant
user--presumably the user responsible for the change. My point is
simply that provenance implicates all of these types:

Organization, Person, User, AuditableEvent

It's about what modifications have been performed to an object during
its life cycle. But I won't belabour the point any more, and no, it
doesn't materially affect usage of the spec.


-- 
Richard