Perhaps to solve the dilemma what we need is a simple statement of the
definition of Provenance as it is used in the spec. This should
eliminate any confusion about how it is used here, and what all is
encompassed in the relationship with AuditableEvent.
Kathryn Breininger
Boeing Library Services
425-965-0182 phone
-----Original Message-----
From: Farrukh Najmi [mailto:]
Sent: Friday, March 11, 2005 9:53 AM
To: Richard Martell
Cc:
Subject: Re: [regrep] Re: [Proposed Resolution] Re: [regrep-comment]
PublicComment
Richard Martell wrote:
> Farrukh Najmi wrote:
>
>> Below is my proposed resolution to Richard's comment...
>>
>> Please comment so I can send formal reply. Thanks.
>>
>> Hi Richard,
>>
>> Thank you for your comment. Please see our response inline below....
>>
>> wrote:
>>
>>> Comment from:
>>>
>>> [ADVISORY] Use of the term "Provenance"
>>>
>>> ---------------------------------------
>>>
>>> The term "provenance" does not seem apt in Section 5.
>>>
>>>
>>>
>>> In the Dublin Core element set, provenance is defined as "A
>>> statement of any changes in ownership and custody of the resource
>>> since its creation that are significant for its authenticity,
>>> integrity and interpretation."
>>>
>>>
>> The term "provenance" is described in Webster Online Dictionary as:
>>
>> *1* *: ORIGIN
>> <http://webster.com/cgi-bin/dictionary?book=Dictionary&va=origin>,
>> SOURCE
>> <http://webster.com/cgi-bin/dictionary?book=Dictionary&va=source>*
>> *2* *:* the history of ownership of a valued object or work of art or
>> literature
>>
>> http://webster.com/cgi-bin/dictionary?book=Dictionary&va=provenance&x
>> =0&y=0
>>
>>
>
> 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.
--
Regards,
Farrukh
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
