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

Re: Resources and state

From: martin <martin@ics.forth.gr>
Date: Wed, 01 Jun 2011 22:47:12 +0300
Message-ID: <4DE69740.4020209@ics.forth.gr>
To: public-prov-wg@w3.org
I also support not talking about states at the first place. Building up the life-cycle of a material object by transitions,
i.e., taking "states for resources themselves" is theoretically much clearer for the beginning, and for information objects,
states anyhow cannot be defined in a context-neutral way, as the SEmantic Web and RDF requires.

Best,

Martin

On 6/1/2011 1:01 PM, Graham Klyne wrote:
> 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).
>>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>


-- 

--------------------------------------------------------------
  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Research Director             |  Fax:+30(2810)391638        |
                                |  Email: martin@ics.forth.gr |
                                                              |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
                                                              |
  Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                              |
          Web-site: http://www.ics.forth.gr/isl               |
--------------------------------------------------------------
Received on Wednesday, 1 June 2011 19:48:03 GMT

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