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

Re: Resources and state

From: Graham Klyne <GK@ninebynine.org>
Date: Wed, 01 Jun 2011 11:01:56 +0100
Message-ID: <4DE60E14.5010502@ninebynine.org>
To: Paul Groth <pgroth@gmail.com>
CC: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, W3C provenance WG <public-prov-wg@w3.org>
Paul,

That's a fair summary, particularly about advocating the second option you list, 
and I agree about the need for debate.  If someone can show me a clear example 
where the second option doesn't work, I'll pipe down :)

I can't arguing with capturing the notions (though to some extent I thought that 
was coming from the XG), but I don't want it to be assumed that *all* of these 
notions have to be represented explicitly in a core model.  I guess what I am 
most concerned about is that we don't "sleep walk" into using a more complex 
model without at least considering why we need it.

#g
--


Paul Groth wrote:
> Hi Graham,
> 
> I'm absolutely with you here.
> 
> I think we want to be able to describing the provenance of resources as 
> simply and developer friendly as possible
> 
> One should be able to simply point to a resource and put some provenance 
> properties on it. i.e. dc:source should fit fine into the model.
> 
> On the other hand, it's clear that many models of provenance take 
> advantage of the notion of state to allow for clear provenance semantics 
> and the possibility of inference.
> 
> The question is, whether
> 1) we  build up from talking about resource state and have conventions 
> for dealing with resources that are dynamic; or
> 2) the other way around. We take resources and then add additional 
> properties to discuss things like states.
> 
> I think you're advocating for 2).
> 
> But in the end the question is really we should capture all notions. 
> Would you agree that resource and resource state are resource 
> representation are all important notions we need to be able to discuss.
> 
> Is that correct?
> 
> Thanks,
> Paul
> 
> 
> 
> 
> Graham Klyne wrote:
>> Luc Moreau wrote:
>>> Hi Graham,
>>>
>>> Isn't it that you used the duri scheme to name the two resource states
>>> that exist in
>>> this scenario?
>>
>> That is a possible way of describing it, but the essence of what I
>> suggest is
>> that the "states" (or "snapshots") are themselves resources.
>>
>>> In your view of the web, is there a notion of stateful resource? Does
>>> it apply here?
>>
>> Resource state is an architectural concept in the web. Indeed, it's so
>> fundamental that the notion is used throughout
>> http://www.w3.org/TR/webarch/
>> without actually being defined, as far as I can tell. (Other than
>> indirectly by
>> reference to Fielding's thesis.)
>>
>> But not all resources have dynamic state. Indeed, probably most
>> resources on
>> the web are static.
>>
>> What I'm trying to do is avoid a layer of modelling complexity that I 
>> don't
>> believe is needed: I think we can say all we need to say by just talking
>> about
>> resources. And in some cases, I think that talking about non-resources
>> can lead
>> to inconsistencies or awkwardness (sorry, no example to hand.)
>>
>> To some extent, this pushes the static/dynamic discussion to a different
>> place,
>> because in some cases the type of a resource may be significant. But I
>> see that
>> as a useful extension point in any case, when discussing possibly
>> conflicting
>> models of provenance and associated inference. What I'd really like to
>> do is
>> simplify the *core* model until there's nothing there for the different
>> provenance models to disagree about.
>>
>> ...
>>
>> Tangentially related, I just read through Yolanda's slides
>> (http://www.w3.org/2005/Incubator/prov/wiki/images/0/02/Provenance-XG-Overview.pdf), 
>>
>> and followed up on some of the associated reports, and my feeling is
>> that there's serious potential here for scope creep.
>>
>> One point in which I am in very strong agreement, indeed, I think it's
>> probably the most important thing for us as a working group, is:
>>
>> Slide 36:
>> "The exchange language should have a low entry point to facilitate
>> widespread adoption, therefore it should be easy to do simple things"
>>
>> I think this is crucial the the eventual success of this group's work
>> (by which I don't mean successfully advancing to REC status, but
>> creating specifications that will actually be used in the web at large).
>> The provenance problem is too important to mess it up my making it too
>> complicated for developers to get started.
>>
>> So, I think that at a basic level of provenance on the web, we want to
>> avoid talking about states, and snapshots, and other constructs that are
>> not directly relevant to a web developer creating an application to
>> record or use provenance information. I think the notion of "resource",
>> interprted broadly per AWWW, etc., allows us to do that. Building upon a
>> very simple core model, the subtleties can be added throug refinement of
>> the core concepts. But if the core concepts are not so simple that
>> developers can easily generate provenance information, this group's work
>> could end up like a magnificently engineered car with no roads to 
>> drive on.
>>
>> #g
>> -- 
>>
>>> On 31/05/11 23:57, Graham Klyne wrote:
>>>> Luc Moreau wrote:
>>>>> Graham,
>>>>>
>>>>> In my example, I really mean for the two versions of the chart to be
>>>>> available at
>>>>> the same URI. (So, definitely, an uncool URI!)
>>>>>
>>>>> In that case, there is a *single* resource, but it is stateful.
>>>>> Hence, there
>>>>> are two *resource states*, one generated using (stats2), and the
>>>>> other using (stats3).
>>>>
>>>> Luc,
>>>>
>>>> I had interpreted your scenario as using a common URI as you explain.
>>>>
>>>> But there are still several resources here, but they are not all
>>>> exposed on the web or assigned URIs. I'm appealing here to anything
>>>> that *might* be identified as opposed to things that actually are
>>>> assigned URIs. (For example, the proposed duri: scheme might be used
>>>> - http://tools.ietf.org/id/draft-masinter-dated-uri-07.html)
>>>>
>>>> (And the URI is perfectly "cool" if it is specifically intended to
>>>> denote a dynamic resource. A URI used to access the current weather
>>>> in London can be stable if properly managed.)
>>>>
>>>> (I think this is all entirely consistent with my earlier stated
>>>> positions.)
>>>>
>>>> #g
>>>> -- 
>>>>
>>>>> Of course, if blogger had used cool uris, then, c2s2 and c2s3 would
>>>>> be different resources.
>>>>>
>>>>> Luc
>>>>>
>>>>> On 05/31/2011 02:25 PM, Graham Klyne wrote:
>>>>>> I see (at least) two resources associated with (c2): one generated
>>>>>> using (stats2), and other using (stats3). We might call these
>>>>>> (c2s2) and (c2s3).
>>>>>
>>>
>>
>>
>>
> 
Received on Wednesday, 1 June 2011 10:10:15 GMT

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