RE: Access and query TF - actions for WG

Without entering the dialog on access mechanism directly, I would like
to note that there are examples where people have decided there's a need
to distinguish thing and thing-as-curated-by-serviceX - The ARK
identifier scheme, and Steven Kunze's discussion of why a two-part
identifier (curator/thing) is valuable, is one reference, and I believe
the Europeana Data model, where they've introduced 'proxies' for things
that are where they hang information about the thing 'as known by' an
organization is another. Both of these examples involve use cases where
distributed independent actors may have knowledge of data/things they do
not own/do not provide access to (perhaps they have copies), which seems
like something we'll have if, for example bloggers don't keep a copy of
the government data but do keep metadata about it.

What we decide about accounts may also influence the access mechanism...

 Jim

> -----Original Message-----
> From: public-prov-wg-request@w3.org [mailto:public-prov-wg-
> request@w3.org] On Behalf Of Luc Moreau
> Sent: Monday, June 20, 2011 11:48 AM
> To: Graham Klyne
> Cc: public-prov-wg@w3.org
> Subject: Re: Access and query TF - actions for WG
> 
> Hi Graham,
> 
> A question is interleaved.
> 
> On 06/20/2011 02:40 PM, Graham Klyne wrote:
> > Luc Moreau wrote:
> >> Hi Graham,
> >> Thanks for the clarification.
> >>
> >> It seems that our two proposals only differ by this:
> >> - your proposal is to provide a provenance-URI where to retrieve
> >> provenance
> >> - mine is to provide an identity I and a service location L, out of
> >> which a provenance-URI can be composed.
> >> Otherwise, I think the proposals are identical.
> >> Would you agree?
> >
> > Er, yes, but that seems to me to be more different than similar.  I
> > think the notion of "composing" a URI from an identity and a
location
> > is problematic and unnecessary.
> >
> > In my view, we just have an identifier, or several identifiers
without
> > specifying how it is (they are) minted, (some of) which MAY also be
a
> > location.  Either way, any identifier can be used with third party
> > services if so desired.
> >
> >> My only motivation for my proposal is that I can use identity I
with
> >> multiple services L1, L2, ... of my choice to obtain different
> >> provenance.
> >>
> >> It would be good to see whether we want to consider this
requirement
> >> or not? Any views in the WG?
> >
> > Of course.  I think I've indicated mine :)
> >
> > (For the avoidance of doubt: I think the possibility of use with
third
> > party services *is* a requirement, but I don't think we need to say
> > anything special about the construction of the identifier to make
that
> > possible.)
> 
> 
> OK, I can use HTTP HEAD in order to obtain provenance-URI for some
resource.
> This provenance-URI will be returned by the same service as the one
> providing the resource.
> 
> How can I obtain an alternative provenance from another service?  I
> don't understand I
> would get an alternative provenance-URI?
> 
> Luc
> 
> >
> > #g
> > --
> >
> >>
> >> Cheers,
> >> Luc
> >>
> >>
> >>
> >> On 06/20/2011 11:29 AM, Graham Klyne wrote:
> >>> Luc Moreau wrote:
> >>>> Hi Graham,
> >>>> Thanks for your comments. You didn't respond to this point, I
think:
> >>>>
> >>>> >What is provenance-uri? is it unique? is provenance found at one
> >>>> and only one place? is there one and only one authority to
provide
> >>>> provenance information about something?
> >>>
> >>> I thought I did, but if I did I was clearly not clear enough.  A
> >>> provenance URI is a URI that is used to identify the provenance of
> >>> some resource.
> >>>
> >>> Comments:
> >>> - it may or may not be dereferencable (preferred web style is that
> >>> it is dereferencable, but that's not a requirement of being a
> >>> provenance URI).
> >>> - it is not unique - there may be several such URIs for a resource
> >>> (but, presumably, the publisher of a resource may have a preferred
> >>> such URI)
> >>> - therefore, there may be several sources for provenance about a
> >>> resource, but the general issue of which is to be considered an
> >>> "authority" is dependent on context that I submit is outside the
> >>> scope of the working group.
> >>>
> >>> I think this covers the scenarios to which you allude below.
> >>>
> >>> #g
> >>> --
> >>>
> >>>
> >>>> (see
> >>>>
> http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal#Com
> ments)
> >>>>
> >>>>
> >>>> When we see a product/advert/etc (e.g. a box of cereals in a
> >>>> supermarket), we can
> >>>> scan its barcode, get its identity, and its provenance from the
> >>>> manufacturer.
> >>>> Your solution seems to support that.
> >>>>
> >>>> I would also like to go to a 'consumer group' offering a
provenance
> >>>> service, and get a different
> >>>> account of the provenance of that product. That's why I suggest
to
> >>>> separate the identity of the
> >>>> 'thing' from the location where we retrieve provenance.
> >>>>
> >>>> Of course, combing them (I and L) together provide a URI, from
> >>>> which provenance is retrieved.
> >>>> So, on this point, we agree: no point inventing another protocol
to
> >>>> retrieve provenance. The key
> >>>> is to find where to retrieve provenance from.
> >>>>
> >>>> Cheers,
> >>>> Luc
> >>>>
> >>>>
> >>>>
> >>>> On 06/20/2011 08:19 AM, Graham Klyne wrote:
> >>>>> So that's it, I think my proposals cover the common cases.  I
> >>>>> recognize that I have not solved the case of a
non-dereferenceable
> >>>>> provenance URI, of where the original server does not provide a
> >>>>> provenance URI, or where the server needs to know if provenance
> >>>>> may be required later when serving a resource.  But I see these
as
> >>>>> orthogonal problems whose solutions we can better craft when we
> >>>>> have a basic common-case framework in place, and I can imagine
> >>>>> possible solutions for both of these (both essentially
third-party
> >>>>> information services that do not need to be
provenance-specific).
> >>>>> I was always clear that my proposals were not exhaustive, but I
do
> >>>>> think they form a sufficient basis for initial work.
> >>>>
> >>>
> >>
> >
> 
> --
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
>

Received on Tuesday, 21 June 2011 15:56:11 UTC