Re: Access and query finalisation for F2F1

All,

I discussed some of this in person with Graham yesterday, but wanted
to reply with my clarifications in case useful for the group.

Please remember the aim is to discuss these as a group at the F2F1,
and for now just decide if they are acceptable and clear enough for
this purpose and to suggest further such points. Graham - I know you
will not be at the F2F1, so take these as your votes in advance.

Clarifying P4, this was derived from a point raised by Stian on the
PAQ Wiki page. If you access a "block" of provenance data, it could
describe the past of many things. If you have accessed it on the
grounds of understanding the provenance of one particular thing, then
you will need to know its identifier in order to find the relevant
information from the block. If that single identifier is not clear
from the block itself, then you need to obtain it from somewhere else.
As far as I can see, this is definitely an access and query issue.

Thanks,
Simon

On 27 June 2011 00:13, Graham Klyne <GK@ninebynine.org> wrote:
> 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
> --
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

Received on Tuesday, 28 June 2011 11:05:51 UTC