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

Re: writing a simple example in prov-o, help

From: Simon Miles <simon.miles@kcl.ac.uk>
Date: Wed, 26 Oct 2011 18:45:50 +0100
Message-ID: <CAKc1nHdrTQcoBvbwvm3mZVmK+p13fnx7+J9vh1d9xvmAQEuiKQ@mail.gmail.com>
To: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Luc,

Wouldn't it be more appropriate in deliverable D6 (best practice
cookbook) to describe topics such as how to be robust to changes? It
could be in the primer, but we'd need to separate the gentle
introduction to how to use the model (which I would see as the
primer's main role) from the consideration of nuanced situations.
These could be distinct parts of the document.


On 26 October 2011 15:50, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:
> Hi Simon and Paul,
> I see this simple example as good because it shows us that
> we don't have to write much to express provenance.
> Better some, than none!
> As always, this comes with some limitations, and I would
> see the role of the primer to discuss potential issues with these
> assertions as the world changes (e.g. video content changes).
> BTW, that's not typical of provenance, but it's typical of any metadata.
> The primer could discuss ways of making the assertions more
> robust to changes.  A range of option exists, but they have to be discussed:
> - cool uris are really OK only for the publisher
> - adding the time at which
> <http://www.ted.com/talks/paul_bloom_the_origins_of_pleasure.html>
>    was used would make those statements much stronger
> - adding further characterization, e.g. hash of the video, etc.
> Luc
> On 10/26/2011 10:53 AM, Simon Miles wrote:
>> Hi Paul,
>> I think the argument you make is the same as implied by my example...
>> except that the conclusion is different.
>> As you say, the provenance best practice could be to use permalinks.
>> So, in the example, the bloggers should use permalinks. They have no
>> control over what the original YouTube URL deferences to, so cannot
>> ensure it is a permalink. Unless they have special information, they
>> can only assume it is not, and so either they:
>>    (a) cannot say anything about the video at all, or
>>    (b) need to create their own permalink to refer to the video.
>> If doing (b), this new URI clearly should connect to the YouTube URL
>> as it is the video that the provenance is about. However, to make it
>> into a permalink, there must be something more which ensures it always
>> describes the same content, i.e. characterisation of the entity. The
>> provenance then looks like the PROV-OM examples rather than the simple
>> link.
>> I'm not clear if you are arguing for option (a) in your email, i.e.
>> limit people to only refer to things in their provenance when they can
>> control those thing's immutability, but this seems very restrictive.
>> I'm not saying I prefer the long-winded provenance data, just that it
>> appears the desire for interoperability makes it necessary beyond
>> limited cases.
>> I think accounts and consistency are tangential issues - there is
>> nothing inconsistent in what is asserted, the inconsistency comes only
>> from the ambiguity of what is being asserted about.
>> Thanks,
>> Simon
>>> The point is that two different people are asserting it. We can't
>>> maintain consistency across the people. This is why we have accounts, no?
>>> I think one way to handle this is to have a best practice where we
>>> suggest people use permalinks (see
>>> http://en.wikipedia.org/wiki/Permalink) or cool-uris.  Indeed, to me
>>> this is probably the best way to introduce entities.
>>> So overall, my suggestion would be to maintain simplicity but suggest
>>> people use uris that refer to content that doesn't change.
>>> But please bring this up in interoperability page.
>>> cheers,
>>> Paul
>>> Simon Miles wrote:
>>>> Paul, all,
>>>> Just to properly understand why what is being discussed is important,
>>>> I wanted to expand your example to a larger use case.
>>>> At time T, you say something about a video on your blog and assert:
>>>> <http://thinklinks.wordpress.com/2011/07/31/why-provenance-is-fundamental-for-people/>
>>>> prov:wasDerivedFrom
>>>> <http://www.ted.com/talks/paul_bloom_the_origins_of_pleasure.html>.
>>>> At time T+1, the video is edited to introduce a previously missing
>>>> segment that undermines the message of your blog entry. The video URI
>>>> stays the same.
>>>> At time T+2, I say something about the (updated) video on my blog and assert:
>>>> <http://inkings.org/2011/10/08/why-provenance-is-pointless/>
>>>> prov:wasDerivedFrom
>>>> <http://www.ted.com/talks/paul_bloom_the_origins_of_pleasure.html>.
>>>> We could then observe:
>>>>    - Even if the above use case doesn't happen to you, by using the
>>>> simplest form of provenance you are opening the possibility of it
>>>> happening and you would not even know about it.
>>>>    - It doesn't help to say that the video owners shouldn't use the same
>>>> URL, because it is not under the control of either those creating or
>>>> consuming the provenance.
>>>>    - There is nothing apparently wrong with either of our assertions
>>>> (except the lack of characterisation), and I don't know anything about
>>>> your blog so don't take it into account in my blog's provenance.
>>>>    - It seems reasonable criteria for interoperability that if you read
>>>> Prov-DM from two separate sources referring to the same entity, then
>>>> either there is an error in (at least) one or they are mutually
>>>> consistent. I couldn't see what this would correspond to in the
>>>> interoperability discussion [1] though.
>>>> Thanks,
>>>> Simon
>>>> [1] http://www.w3.org/2011/prov/wiki/Interoperability
> --
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166
Received on Wednesday, 26 October 2011 17:46:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:03 UTC