Re: Access and query finalisation for F2F1

Simon Miles wrote:
> Hello PAQ task force, all,
> 
> As said in the telecon, we would like to identify clear points
> regarding access which we can aim to decide on in the limited time
> available at the F2F1. As there is not yet clear consensus regarding
> proposed mechanisms, these points may be mechanism-independent, but
> should help us move towards agreement on the technical details. If
> there is time available, we can then have open discussion on the range
> of mechanisms proposed.
> 
> To start, I suggest the following points, all raised on the Wiki or
> mailing list. It would be great if any of you could:
>  - Comment on the overall approach of starting with such points at F2F1
>  - Suggest more such points
>  - Say whether the points suggested below are adequately precise
> Note that it is not our aim to debate/decide on these points ahead of F2F1.
> 
> P1. There may be data regarding the provenance of a thing accessible
> from multiple sources.

Yes.

> P2. The information required to obtain access to some provenance of a
> thing may be supplied in many different ways, and we do not aim to
> enumerate them all.

Yes.

> P3. The WG effort will concern how the provider of a thing can supply
> information required to obtain access to some provenance of that thing
> (which may, as a side effect, include recommendations on how others
> can do the same).

I think the provider is a useful starting point.

> P4. Regarding some provenance data obtained from dereferencing a
> provenance URI, calling a provenance service, or some other means.
> Which of the following is true?
>   (a) It is apparent from the data itself what single thing it
> describes the provenance of.

Isn't that a question for the model task force?  (Though I think the answer 
should be yes.)

>   (b) Provenance data documents a set of things and how they are
> related by past occurrences, so to extract the provenance of any one
> thing requires knowing how it is identified in the data.

I don't fully understand this; it seems rather non sequitur, though I think I 
agree with the conclusion.  This also feels as it veers close to model territory 
and/or application design.

>   (c) Something else.
> 
> P5. Regarding some provenance data obtained from dereferencing a
> provenance URI, calling a provenance service, or some other means.
> Which of the following is true?
>   (a) To meet the standard, it should be immutable.
>   (b) It can change over time without restriction.
>   (c) To meet the standard, there are particular ways in which it
> should not change, e.g. any one account should remain as it was.

I don't know.  The standard should specify what is needed for interoperability. 
  It may be that meaningful applications have to assume/assert further truths. 
I think the answer is (b) or (c).

#g
--

Received on Sunday, 26 June 2011 23:14:01 UTC