W3C home > Mailing lists > Public > public-prov-wg@w3.org > May 2012

Re: Proposal on PROV-DM reorganization

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Tue, 22 May 2012 09:33:44 +0100
Message-ID: <EMEW3|534cba18c6130c6435dc904a8e2a84bao4L9Z508l.moreau|ecs.soton.ac.uk|4FBB4F68.9040004@ecs.soton.ac.uk>
To: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
CC: Paul Groth <p.t.groth@vu.nl>, Provenance Working Group WG <public-prov-wg@w3.org>
Hi Graham,

Quick feedback

On 22/05/2012 07:16, Graham Klyne wrote:
> Luc,
>
> I just took a quick look.  I think this is a useful improvement for 
> someone approaching provenance.  I won't repeat here all the comments 
> I made previously since you indicate this is a work-in-progress.
>
> My main comment on your structure is that I think derivation in 
> section 2 should be "up there" with entity and activity - I would 
> probably aim to use this section to introduce the notion of a 
> provenance trace.  Even if derivation is treated separately in section 
> 5, for the introduction I think it's part of the entity-activity 
> pattern.  (This comment is based on an understanding that derivation 
> is an entity-entity relation that indicates there is a chain of 
> used/generated property pairs between the entities.  But this isn't 
> stated explicitly - am I misunderstanding something here?)

I think the key point about the "incremental pattern" of Derivation is 
that the used/generated properties may not have been asserted. Also, it 
is not a sufficient condition for derivation, but a necessary one. So, 
that's why for me, derivation is not in the same grouping.
>
> I can't see any purpose served by table 2.
>

It's the only place in the introduction where we map concept names to 
properties names.  Otherwise, how can someone reading the definition of 
'Derivation' know for sure it's realized by property wasDerivedFrom?

> In table 3, I'd suggest dropping the tick-columns for core/extended 
> structures - I think the section cross-references are sufficient 
> (though I note that some link to the wrong place - but I assume that's 
> because this is WIP).  I'd also suggest including forward links to the 
> corresponding sub-sections in section 5.
>
I dropped the extended column, since all components had it. I also fixed 
the links and added foreard links to section 5.

> I think your section 2 can be made into a compact and 
> easily-assimilated overview of core provenance structure.  Looking at 
> this, I think the light-touch treatment here of the extension 
> structures is also useful (which is back-tracking slightly on one of 
> my earlier comments).  If we go ahead with this broad structure, I'll 
> come back later and make more detailed editorial suggestions as seems 
> appropriate.
>
Please, suggestion welcome on section 2.2. There is a tension between 
light touch (and still useful) and too detail.  While
I want to remain light touch, I am not convinced it is all entirely 
useful or understandable.

> I haven't yet looked in detail at the subsequent sections.  My main 
> structural criteria for these would be that specific entries are 
> easily located when the document is used for reference purposes, and 
> the document structure seems to provide that.
>
> With reference to your comments re. section 3 - I would be inclined to 
> move it into the introduction section, but also to trim the 
> explanation and rely more on the referenced prov-n document.  A brief 
> description of the purpose of PROV-N, a link to the specification and 
> maybe the examples should be enough, I think.

I had some push back to move this in section 1, since this document is 
not about serialization.
>
> I (still) think the position of the example (section 4) between the 
> overview (section 2) and the more detailed descriptions (section 5) 
> breaks the flow of the reference material.  I think this is less of a 
> problem than it was, as the first-time developer can switch from 
> "sequential reading mode" to "reference mode"

OK. I am toying with the idea of moving the second subexample (section 
4.2) till after the reference section, and make it use some of the 
extended constructs.

Luc
>
> #g
> -- 
>
>
> On 21/05/2012 22:32, Luc Moreau wrote:
>> Hi Graham,
>>
>> I have been experimenting with section 2, and early preview
>> is visible from
>>
>> https://dvcs.w3.org/hg/prov/raw-file/tip/model/working-copy/wd6-prov-dm-with-core.html 
>>
>>
>>
>> Some responses to your comments.
>>
>>
>> On 21/05/12 12:15, Graham Klyne wrote:
>>> Hi Paul,
>>>
>>> Re: http://www.w3.org/2011/prov/wiki/ProvDM_ConsensusProposal
>>>
>>> I think this proposal is an improvement, though it goes less far than I
>>> personally would choose. I would still prefer a stand-alone document 
>>> covering
>>> the core patterns, but there is apparently no appetite for that 
>>> within the
>>> working group so I shall not push that point.
>>>
>>> Beyond that, here are some specific suggestions relating to your 
>>> proposal:
>>>
>>> 1. I'd prefer to see core patterns as a separate top level section 
>>> rather than
>>> a sub-section of the overview. I feel that would help to convey its 
>>> role as a
>>> self-contained set of related ideas around which the others 
>>> structures and
>>> terms can be used as needed.
>>>
>>
>> I now have three subsections in section 2, respectively related to core,
>> extended, and components.
>> I feel they fit well in an overview section. Moving one or all of 
>> them to the
>> toplevel would lead to a proliferation
>> of toplevel sections, which I am not keen on.
>>
>>> 2. I'd like the diagram to be at the *start* of the core patterns, 
>>> not at the
>>> end. I believe it can provide a mental framework for a reader to 
>>> relate the
>>> concepts as they are described in the ensuing sections. I'd also 
>>> suggest the
>>> diagram (per current DM) be revised to be visually styled more like 
>>> the one in
>>> the PROV-O document. (I'll help with that if asked.)
>>>
>>
>> Yes, it's done.
>>
>> The diagram was updated, using another tool.
>> Now, one can possibly improve on the diagrams, but we do not want to 
>> introduce
>> an ad-hoc graphical notation. We use UML for all our class diagrams.
>>
>>
>>
>>> 3. I would not separate Entities/Activities and Derivation into 
>>> separate
>>> sub-sections. When we talk about using provenance in applications, I 
>>> note that
>>> we most commonly talk about a "provenance trace" - and it is the
>>> interconnection of entities, activities, generation and usage that 
>>> gives us
>>> derivation, which in my perception is a central element of a 
>>> provenance trace.
>>> Thus, I would suggest presenting these concepts together, then 
>>> introducing
>>> agents and associated inter-relationships in a separate sub-section. 
>>> I think
>>> this is what Tim suggested in the last teleconference.
>>
>> The reason for keeping this subsection is that I want to parallel the 
>> component
>> structure.
>> If people are happy with moving component 3 before component 2 (talk 
>> about
>> derivations before agents),
>> I am happy to do so. However, I received some push back.
>>
>>>
>>> 4. I'm not sure that "advanced" is the best term for features that 
>>> are not
>>> part of the core pattern. I can live with it, but I'll also try and 
>>> come up
>>> with some alternatives.
>>
>> Now using extended.
>>>
>>> 5. I'm all for looking to improve modularity of the design, as you also
>>> mention in your proposal.
>>>
>>
>> It's an important aspect of the DM and therefore has been given an 
>> overview
>> section in 2.3
>>
>>> 6. I'm not sure that it really adds any value to mark core patterns 
>>> throughout
>>> the document as you suggest. Once a reader has internalized the core 
>>> patterns,
>>> I think they're pretty obvious when they occur.
>>>
>>
>> The only mark up occurs in tables 3/4, section 5. I am not proposing 
>> to do it
>> anywhere else.
>>
>> Cheers,
>> Luc
>>
>>> #g
>>> -- 
>>>
>>>
>>> On 20/05/2012 11:01, Paul Groth wrote:
>>>> Hi All,
>>>>
>>>> During last week's telcon [1] the chairs were tasked to come-up with a
>>>> proposal that tried to reflect consensus on reorganization of the data
>>>> model. This would take into account both Graham's proposal [2] as well
>>>> as the WG discusion and prior agreements.
>>>>
>>>> We've come up with with the following proposal:
>>>>
>>>> http://www.w3.org/2011/prov/wiki/ProvDM_ConsensusProposal
>>>>
>>>> We hope this reflects a consensus with the working group and something
>>>> we could proceed on. Is this a good foundation to proceed?
>>>>
>>>> Thanks
>>>> Paul
>>>>
>>>>
>>>> [1] http://www.w3.org/2011/prov/meeting/2012-05-17
>>>> [2] http://www.w3.org/2011/prov/wiki/ProvDM_Proposal_for_restructuring
>>>>
>>>
>>
Received on Tuesday, 22 May 2012 08:35:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 08:36:01 GMT