Re: Resources and state

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 08:17:31 UTC