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

Re: PROV-ISSUE-229 (Refactor-and-sub-edit): Document would benefit from refactoring and editing [prov-dm]

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Tue, 31 Jan 2012 12:10:05 +0000
Message-ID: <EMEW3|09c44f062c76d31f3417f9a8aa339b47o0UCA908L.Moreau|ecs.soton.ac.uk|4F27DA1D.5080406@ecs.soton.ac.uk>
To: Paolo Missier <Paolo.Missier@ncl.ac.uk>
CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Hi Paolo,
The only things that have been agreed are the proposals recorded in minutes.

No agreement on record and account record.

I agree with you that no editing can take place until we agree on 
identifiers and accounts.


On 01/31/2012 11:55 AM, Paolo Missier wrote:
> Hi,
> can someone clarify the outcome of the vote on the "universe of 
> discourse" (UoD) proposals? (I missed the call and that's not clear 
> from the minutes)
> I thought at this point we have a correct and complete list.
> I would also want to clarify waht UoD means. Is it "all and only the 
> things whose provenance can be expressed using PROV-DM"?
> IMO attributes are a "weak entity", they don't really stand on their 
> own.  But the proposed changes are purely syntactic, right? i.e. 
> structured vs flat terms. So I don't see it as a priority.
> there are indeed strange phrasings here and there but editing /is/ 
> ongoing and pretty much continuous. But I would hesitate to 
> restructure the entire doc around this new UoD idea, at least until it 
> settles.
> Thanks, -Paolo
> On 1/31/12 9:15 AM, Luc Moreau wrote:
>> Hi Graham,
>> Some comments inline.
>> On 01/30/2012 10:48 AM, Provenance Working Group Issue Tracker wrote:
>>> PROV-ISSUE-229 (Refactor-and-sub-edit): Document would benefit from 
>>> refactoring and editing [prov-dm]
>>> http://www.w3.org/2011/prov/track/issues/229
>>> Raised by: Graham Klyne
>>> On product: prov-dm
>>> I am finding some of the text to be repetitive, confusing and in 
>>> some cases strangely phrased.  I think a main goal of this document 
>>> needs to be to offer an approachable description of the underlying 
>>> data model and ASN notation that can be used by developers and 
>>> information designers.  I think the document could benefit from a 
>>> serious round of sub-editing (without intending to change the 
>>> substantive content).
>> It would be useful if you (maybe face to face in AMS) could point to
>> sections which you find repetitive, confusion and strangely phrased. We
>> can work on them.
>>> I also think that a refactoring of the DM concepts (without 
>>> fundamentally changing the underlying intended semantics) could help 
>>> to eliminate a lot of repetitive text.  These comments relate to the 
>>> recent "domain of discourse" vote, but I'm coming at this from a 
>>> more holistic perspective.
>>> It seems to me that the domain of discourse contains the following 
>>> concepts:
>>>     Entity
>>>     Activity
>>>     Agent
>>>     Event
>>>     Plan
>>>     Account
>> Definetely no agreement for account.
>> To add to the list collection.
>>> in that these are the various things about which the provenance 
>>> language aims to make assertions, and that all of these could be 
>>> considered types of Entity (with the possible exception of Event).  
>>> I think we've already established that most if not all of these are 
>>> kinds of entity.
>>> If the descriptions were refactored around such a structure, I 
>>> believe much of the repetitive description of attributes could be 
>>> focused in one place.  I would be inclined to separate attributes 
>>> from the other type declarations, so we'd end up with primitive ASM 
>>> expressions like these:
>>>     Entity(id)
>>>     Activity(id, start?, end?)
>>>     Agent(id)
>>>     Plan(id)
>>>     Event(Id, time?)
>>>     Account(id)
>>>     Attributes(id, [attr1=val1, attr2=val2, ...])
>> I don't understand what you save with this syntactic rewriting. Can you
>> clarify?
>>> Where the Attributes expression could be applied to any of the 
>>> preceding concepts, and the description of attributes would 
>>> consequently be needed only once.  The main objection I see to this 
>>> is that it would mean that, say, the ASN expression:
>>>     Entity(id, [attr1=val1, attr2=val2, ...])
>>> would be replaced by two expressions:
>>>     Entity(id)
>>>     Attributes(id, [attr1=val1, attr2=val2, ...])
>>> I would counter this by having the ASN (but not the underlying 
>>> model) allow the first form as a syntactic sugar for the second.
>> This seems to imply that Attributes, can be explain by themselves, that
>> they are standalone.  Not sure this still corresponds to this idea of
>> characterized thing we had for entity.
>>> I also felt that the handling of Activity start and end was not 
>>> consistent:  according to the text, the times given correspond to 
>>> Events.  So why not have them *be* Events - that would mean we have 
>>> a total of 6 event types rather than just 4, but the description of 
>>> the "Lamport clock" timelines could be focused on the description of 
>>> Event alone.
>> If I understand correctly,  that's exactly the purpose of ISSUE-207.
>> I don't understand however, why it gives you 6 event types rather 
>> than 4.
>>> ...
>>> I think all of this could be done with minimal change to the 
>>> underlying semantics, and that coupled with a significant round of 
>>> sub-editing and reorganization of some of the text could lead to a 
>>> document that is much easier to follow.
>> Once the discussion on identifiers converges, including agreement on
>> accounts, then we can undertake this revision.
>> That's the plan for WD4.
>> Luc
>>> #g
>>> -- 

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
Received on Tuesday, 31 January 2012 12:10:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:11 UTC