Re: Resources and state

On 01/06/2011 09:16, Paul Groth wrote:
> 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 that this summarize nicely the discussion we had about resources 
so far.


> 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
>> 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
>> (, 
>> 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
>>>> -
>>>> (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 Friday, 3 June 2011 12:35:07 UTC