Re: Resources and state

> So I would be inclined to to agree that we should avoid mission creep
> concerning resource state, and maybe go further: while recognizing the
> importance of dynamic state, versioning, containers, etc. for
> provenance, we should scope the model as narrowly as possible, and ask
> for each concept whether it is really something that needs to be
> standardized in order to provide minimal , and whether it is well-
> understood enough not to be a research problem.

+1. Totally agree. As long as we have a clear definition and scoping, 
(sensible) people adopting our standard would be careful about how to 
apply it most accurately. If anything out of the scope, we could either 
address them in a cookbook-like best practice recommendation, for 
handling, such as containers, versioning etc, or let profiles emerge by 



For some of these, we
> might consider extensibility mechanisms (eg OPM-syle "profiles") to
> accommodate experimentation without presuming to standardize something
> prematurely.
> </soapbox>
> --James
> On Jun 1, 2011, at 8:20 AM, 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 Thursday, 2 June 2011 11:55:54 UTC