> Luc,
   > all,
   > 
   > I've been looking at PROV-DM today.
   > 
   > I'm happy for it to go to last call with "MentionOf" at risk, possibly
   > with attention to other points noted below.  I think there are still
   > editorial improvements possible, but for the most part the thrust and
   > intent is acceptably clear, and I think further editorial improvement
   > can be made in the period following last call.
   > 
   > ...
   > 
   > In section 5.5.3, I believe example 46 is incorrect.  The mentionOf
   > expressions used imply that ex:report1 and ex:report2 are bundles when
   > the defintion of mentionOf is taken into account.  I don't think this
   > is intended.

Yes, James pointed this out too. 

   > 
   > (This comment is completely independent of my opposition to the
   > mentionOf construct as currently proposed.  I intend to construct my
   > case for this based on the final documents that go forward to last
   > call.  I would, however, drop my opposition if mentionOf is reduced to
   > a 2-place predicate like mentionOf(entity, bundle).  I mention this
   > here simply to be clear about my position.)
   > 
   > ...
   > 
   > In section 5.1.6, I'm finding the treatment of wasStartedBy is not
   > straightforward.  The distinction between "trigger" and "starter"
   > seems a bit arbitrary.  In this context, it seems to me that an
   > activity may be started by another activity, which in turn may be
   > associate with an agent.  Or, to put it another way, an agent only
   > triggers an activity through association in another activity, thus:
   > 
   >   wasStartedBy(a1, a2) (activity a1 was started by activity a2)
   >   wasAssociatedWith(a2, ag) (agent ag was associated with activity a2)
   >   or wasInfluencedBy(a2, e) (entity e influenced activity a2)


   > 
   > So I'm thinking that wasStartedBy could be simplified by dropping the
   > entity parameter.  But that doesn't completely address my uncertainty.
   > 
   > Part of my problem here is that it's all a bit unclear, and I can see
   > different ways of expressing the idea that an agent started an
   > activity:

Just to be clear, wasStartedBy is not about agents/responsibility.
It links an activity to the bit of information/entity that made
the activity start.


   > 
   > 1: wasStartedBy, as currently definbed 2: indirectly via another
   > activity, as suggested above 3: by direct involvement, as in
   > wasAssociatedWith(a, ag, [role="ex:startedBy"])
   > 
   > Such diversity of modeling options makes it harder to reconcile and
   > reason over information coming from disparate sources.
   > 
   > I don't see this as a blocking issue, but I think ti would make it
   > easier for people to generate provenance consistently if the options
   > on wasStartedBy could be simplified.
   > 


There was a long debate and a WG resolution on this topic.

   > ...
   > 
   > Section 1.2
   > 
   > I think this should be split into two separate sections:
   > 
   > 1.2 Notational conventions
   > 
   > 1.3 Namespaces
   > 
   > When looking at documents, I often look in the table of contents to
   > locate the namespace URIs, so having them buried under notational
   > conventions is not most helpful.
   > 

Done.

   > ...
   > 
   > Section 2.2, para 1
   > 
   > Suggest "more advanced uses of provenance" --> "more specific uses of
   > provenance"
   > 
   > ...

OK
   > 
   > Section 2.2.3
   > 
   > reading this, it's not clear to me why this specification s relevant
   > to provenance description.  I think that, from a provenance
   > perspective, the essence of example given could be expressed without
   > knowing about the member/collection relationship.
   > 
   > 

Do you mean why collections are relevant to provenance descriptions?

...
   > 
   > Section 3
   > 
   > The brief introduction to notation does not mention the form of names
   > used, or their correspondence to URIs (namespces, etc.).  I think this
   > is at least as relevant to the following materials as the summary of
   > functional notation and optional parameters.
   > 
   > ...


What we can say here is limited to their syntax. The fact they are mappable to IRIs
the notion of namespace etc, is introduced in sections 5.7.1 and
5.7.5, it's not specific to prov-n.


So, I have added the following sentence:

<li>The PROV data model defines <em>identifiers</em> as qualified names; in PROV-N, they are expressed as a local name optionally preceded of a prefix and a colon. </li>



   > 
   > Section 5.1.8, example 28
   > 
   > I'm finding it hard to see "buy one beer, get one free" as an
   > *entity*.  I'd suggest dropping this example, as it seems rather
   > contrived to me.
   > 


It's a good example. Similar to a winning lottery ticket, claimed or not claimed.


   > ...
   > 
   > Section 5.6.2, memberOf parameter "complete"
   > 
   > I'm not seeing a clear distinction betweenthe 2nd and 3rd options
   > here.  They both seem to mean "there may be more, but we don't know
   > for sure", and differ only in the amount of certainty expressed.  I
   > think the key distinction here is 2-way: either the collection is
   > closed (all members are known), or it is open (there may be more).
   > Trying to draw a finer distinction here I think does not help in any
   > meaningful way.
   > 
   > ...


Updated as you suggested, closed or open.

   > 
   > Section 5.7.4
   > 
   > The namespace URI for PROV is already given in section 1.  Repeating
   > it here is a hostage to fortune, and I don't think it serves any
   > useful purpose here.
   > 
   > ...

No change here.


   > 
   > End of comments.
   > 
   > #g --
   > 
   >