RE: PROV-ISSUE-1 (define-resource): Definition for concept 'Resource' [Provenance Terminology]

They could be separate accounts, but that leads to two questions - 
Do the legal and physical witnesses use the same identifiers in their
accounts? If so, we have a paradox/the witnesses appear to disagree. If
not, we can't connect the accounts.
If I'm a provenance aggregator (or we have a judge who would like to
read both accounts and make some claim about what the overall truth is),
how can I represent things in a way that shows that there is no paradox
in this case (that the legal and physical objects diverge over time)? 

I would expect that in simple/low-level accounts, we'll often be talking
about only one perspective (or will think we are) and thus the world
looks relatively simple - some mutable thing has states that go through
processes to produce new states, but thinking of mutable things that are
related to 'things that hold some aspects of state constant' (legal
state, physical state, some physical state but not other parts of
physical state) allows the more general case. And, when we think we're
in the simple case but we find a paradox, or want to talk about agents
or sources around the edges of our main provenance trail, small bits of
the general case will sneak into an account.

Does that make sense?


> -----Original Message-----
> From: [mailto:public-prov-wg-
>] On Behalf Of Paolo Missier
> Sent: Monday, June 06, 2011 10:26 AM
> To:
> Subject: Re: PROV-ISSUE-1 (define-resource): Definition for concept
> [Provenance Terminology]
> Jim
> isn't the legal/physical distinction from your example an instance of
> "accounts" (in OPM terms), i.e., different observers collecting
> sequences of events, which may partially overlap. This is just to
clarify, it
> seems to be we do have concepts to deal with this distinction.
> Regards, -Paolo
>   On 6/2/11 3:15 PM, Myers, Jim wrote:
> > This issue is not just aggregation. I have an iPass and the state
considers any
> vehicle with that iPass in it to be mine and expects me to pay tolls
when it
> engages in drive-on-tollway events. There are times when that legal
vehicle is
> my physical car and times when its a rental. (I.e. I would not say my
car had
> all its parts replaced when I use a rental car).
> >
> > I think we have exactly this issue in our scenarios - the
legal/logical data
> from the goverment corresponds to different physical file objects at
> times and we want to track provenance across the legal/logical and
> processes that occur. We are asking in queries whether the logical
> depends on the government data even when all of the physical bits of
> input used are completely different (on a different disk, perhaps in a
> format) than the government data file. If we don't track the logical
> government data separately from physical files that at times are
> manifestations of it, we get paradoxes from our limited model that
don't exist
> in the real world. (File copying preserves the logical-to-physical
> correspondence, editing a file to be all zeros does not, so if you
have a
> derived result from any copy created before an edit occurred, you're
result is
> logically dependent on the government data...).
> >
> > We really have these types of logical to physical relationships
> science as well - we assume the reading from the sensor is the logical
> temperature but would question that relationship if we had provenance
of a
> 'smashed' event for the sensor. The logical temperature may at times
> separate provenance from the sensor reading and we may want to track
> >
> > In a practical sense, I think modeling this way involves very little
change to
> OPM-style provenance. In addition to artifact-process
execution-artifact type
> chains, you have the occasional links that connect resources -
physical file is a
> manifestation of the gov data - that allow you to cross from thinking
> legal/logical/intellectual provenance to physical/computational
> etc. That 'minor' addition would avoid further discussion of how/when
> categorize specific things as mutable/immutable, etc. and probably
> the need for special case opm:agent and pml:source style types as
> >
> >   Jim

Received on Monday, 6 June 2011 16:21:21 UTC