W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2011

Re: Access and query finalisation for F2F1

From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
Date: Tue, 28 Jun 2011 15:36:36 +0200
Message-ID: <BANLkTimsjpBXJSRzJd2yB5hE6F-JeA_ybA@mail.gmail.com>
To: Simon Miles <simon.miles@kcl.ac.uk>
Cc: Provenance Working Group WG <public-prov-wg@w3.org>
2011/6/26 Simon Miles <simon.miles@kcl.ac.uk>

> 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.
>
I agree. But right now in the proposal it is an issue beyond scope (despite
some
proposal already address the issue) ->should we remove the comment from
Yogesh at the end?

>
> 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.
>
True, but it wouldn't be bad if we suggest/recommend to use some ways to
the provenance publishers.

>
> 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).
>
Agreed.

>
> 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.
>
 (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.
>  (c) Something else.
>
 I would say a). After Simon's clarification, I think that b) is important
too,
but have we got any real use case in that scenario?

>
> 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 would take a) to start. Once solved, we should also address b).
If the provenance service changes the provenance
results regularly, it would have to add additional metadata to know what
is the expiry date of the provided information (or else we would have
a lot of conflicting provenance records about the same thing).

Best,
Daniel

>
> Thanks,
> Simon
>
>
Received on Tuesday, 28 June 2011 13:37:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:32 GMT