W3C home > Mailing lists > Public > public-xg-prov@w3.org > October 2010

Re: A proposed provenance wg draft charter

From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
Date: Mon, 25 Oct 2010 21:04:50 +0200
Message-ID: <AANLkTi=wQKNhWx_XQSN88QxKM8gK1Pq-Y3ut2RnAaJ8p@mail.gmail.com>
To: pmissier@acm.org
Cc: Olaf Hartig <hartig@informatik.hu-berlin.de>, public-xg-prov@w3.org
Hi Paolo, all.
In the OPM, artifacts are defined as "inmutable pieces of state", so if a
resource changes in any way(it changes its state),  wouldn't that led to a
new artifact derived from the original one? I think that that's what Olaf
means when he says that we can not track the provenance of a resource, only
the provenance of the "snapshots" or "representations" from that resource
(please correct me if I'm wrong).

Versioning is one of the aspects that is not well captured by OPM according
to the conclusions of the Provenance Vocabulary Mappings, so it should be
one of the "refinements" to be done to the model in order to build a

2010/10/25 Paolo Missier <pmissier@acm.org>

> Olaf,
>  why wouldn't resources have provenance?
>> The problem is that a Web resource may change; it may have a different
>> state at
>> a different point in time. What would the provenance of such a changing
>> thing
>> be?
> well, if a resource changes its state, I would assume that its provenance
> will actually account for those state changes? isn't that within the scope
> of its model?
>  A specific representation of a Web resource cannot change. That's why I
>> find it
>> much easier to talk about the provenance of such representations rather
>> than
>> the Web resource itself.
>> That's probably also why artifacts in OPM are immutable pieces of state.
> ok, but in my mind artifacts (in the OPM sense, for example) stand for
> resources, rather than their representations.
> maybe I don't quite understand what you mean by a representation of a
> resource, here. If a resource changes its state, wouldn't its representation
> (whatever it is) change as well?
> I would find it natural to talk about data versioning (accounting for state
> changes) along with data dependencies (amongst specific versions of a set of
> resources), within the same provenance framework.
>  just like a piece of data in a database.
>> In the case of a database I would also prefer to associate provenance with
>> manifestations of the data. For instance, given a table, I would not
>> associate
>> provenance with the table per se but with a specific version / state of
>> the
>> table. Same with a cell in such a table: I would associate provenance with
>> a
>> specific attribute value thats in the cell rather than with the cell
>> itself.
> sure, although these two are not the same example: the former is
> associating provenance to a version, which is pretty much what I was
> implying above, while the latter is a matter of granularity within the same
> state -- but I agree that both should be there
>  I see it the opposite way: isn't the provenance of a
>>> manifestation of a resource is just (some view of) the provenance of the
>>> resource itself?
>> I wouldn't say so. What you say would mean that multiple different
>> manifestations of the same (state of the same) Web resource have the same
>> provenance (even if different views on it). Shouldn't they have different
>> provenance (even if several pieces of their provenance are overlapping)?
>> Let's say, both of us retrieve a representation of a Web resource; we do
>> it at
>> the same point in time; so, if we are lucky, we have two representations
>> that
>> represent the Web resource in the same state. Nonetheless, I think these
>> two
>> representations have different provenance.
> ok, but isn't their difference "only" in the last, retrieval step? they
> effectively represent the same resource, under the retrieval conditions you
> describe, only the last access step changes, and it's not clear to me that
> that is part of the resource's provenance
> interesting thread, anyway -- not sure it will have an impact on the
> proposed charter though :-)
> -Paolo
Received on Monday, 25 October 2010 19:05:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:59 UTC