issue 437
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Mon, 09 Jul 2012 08:20:15 +0100
changeset 3793 fdeb79f54131
parent 3792 5dd65561cf1e
child 3794 bbe46c9db287
issue 437
model/comments/issue-437-graham.txt
model/comments/issue-437-james.txt
model/comments/issue-437-jun.txt
model/comments/issue-437-satya.txt
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-437-graham.txt	Mon Jul 09 08:20:15 2012 +0100
@@ -0,0 +1,130 @@
+   > 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.
+   > 
+   > (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:
+   > 
+   > 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.
+   > 
+   > ...
+   > 
+   > 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.
+   > 
+   > ...
+   > 
+   > Section 2.2, para 1
+   > 
+   > Suggest "more advanced uses of provenance" --> "more specific uses of
+   > provenance"
+   > 
+   > ...
+   > 
+   > 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.
+   > 
+   > ...
+   > 
+   > 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.
+   > 
+   > ...
+   > 
+   > 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.
+   > 
+   > ...
+   > 
+   > 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.
+   > 
+   > ...
+   > 
+   > 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.
+   > 
+   > ...
+   > 
+   > End of comments.
+   > 
+   > #g --
+   > 
+   > 
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-437-james.txt	Mon Jul 09 08:20:15 2012 +0100
@@ -0,0 +1,50 @@
+   > > > 
+   > > > Question for reviewers: Can the document be published as Last Call working draft?
+   > Yes, but please take note of suggestions below.
+   > 
+   > 0. I don't understand the rationale for deciding who is an author.  I
+   > believe it is up to the editors, but there are some things that I've
+   > helped with here, and I'm not listed (examples: definitions of
+   > specialization/alternate, and semicolon syntax for optional
+   > identifiers).  I haven't directly written much so wouldn't fight to be
+   > included, but at this point I have probably done more than for PROV-O,
+   > where I am listed as an author. (I also wouldn't fight to stay listed
+   > there but am happy to stay listed.)
+   >  
+   > Also, should some of the authors of PROV-DM also be listed on PROV-N
+   > or PROV-CONSTRAINTS, since they were split up?  Having become an
+   > editor of the latter only recently, I would like to make sure we
+   > credit people that contributed to it.
+   > 
+   > 1. S5, "itself dependen on" - spelling
+   > 
+   > 2.  Table 5 and sec. 5.6.2: I have trouble reading
+   > "memberOf(c,{e1,...,en})" - the elements e1,...,en are members of c,
+   > not the other way around.
+   > 
+   > Moreover, I don't understand why memberOf needs to be so complex, with
+   > an id and attributes, if it is just a "hook" for linking up with other
+   > vocabularies that have membership.  Why not just "memberOf(element,
+   > collection)"?  This is what I thought we agreed at f2f3.  We could
+   > also omit EmptyCollection and the completeness flag.
+   > 
+   > 3.  Figure 7 and 7b: I suggest renumbering, or renaming "Figure 7" to
+   > "Figure 7a"
+   > 
+   > 4.  S5.3.5.  "capacity an entity" -> "capacity of an entity"
+   > 
+   > 5.  Example 45.  I am afraid I don't understand how the current
+   > definition of mentionOf accommodates the example.  Why doesn't bondle
+   > tool:analysis1 rate the two activities Bob was associated with (or the
+   > associations themselves) rather than rating (different mentions of)
+   > Bob?
+   > 
+   > 6.  In example 46 (which I'm also not sure I understand, but never
+   > mind), the bundles in mentionOf are the second arguments, I think they
+   > should be third.
+   > 
+   > 7.  I would also suggest that the bundle in mentionOf should be
+   > mandatory, not optional.  -- The University of Edinburgh is a
+   > charitable body, registered in Scotland, with registration number
+   > SC005336.
+   > 
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-437-jun.txt	Mon Jul 09 08:20:15 2012 +0100
@@ -0,0 +1,195 @@
+   >    > Hi Luc and Paolo,
+   >    > 
+   > 
+   > Although I didn't sign up as a reviewer, I thought you could make do
+   > with some additional reviews.
+   > 
+   > On 28/06/2012 22:55, Provenance Working Group Issue Tracker wrote:
+   > > PROV-ISSUE-437 (prov-dm-post-f2f3-review): Final review before last call vote [prov-dm]
+   > >
+   > > http://www.w3.org/2011/prov/track/issues/437
+   > >
+   > > Raised by: Luc Moreau
+   > > On product: prov-dm
+   > >
+   > >
+   > > This is the issue to collect feedback on the prov-dm document (version created after F2F3)
+   > >
+   > > Document to review is available from:
+   > >
+   > > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120628/prov-dm.html
+   > >
+   > > Question for reviewers: Can the document be published as Last Call working draft?
+   > 
+   > Yes, as long as the construct of mention remains as being at risk.
+   > 
+   > Some minor comments are as included below:
+   > 
+   > Abstract:
+   > 
+   > - and, (5) --> ; and (6)
+   > 
+   > - I guess PROV-DM is PROV data model? It will be nice to define this
+   >   abbreviation in the first place of mentioning. This also applies to
+   >   the introduction section.
+   > 
+   > - From the abstract, it's not clear to me the relationship between
+   >   this document and the other companion documents, although I know
+   >   what this is. It will be nice to say clearly whether all of them are
+   >   recommendations? Does PROV-DM refer to this document only or the
+   >   three of them as a whole? It's a small thing, really.
+   > 
+   > 
+   > Status of this document
+   > - Is this the sixth public release?
+   > - prov-o is not an OWL-RL ontology, but OWL-RL++.
+   > 
+   > - Do we have a PROV-XML? I am not aware of this, and just pointed it
+   >   out that this is mentioned.
+   > 
+   > Section 2.1
+   > 
+   > - Before the table, when saying "in the core of PROV, all relations
+   >   are binary", might be worthwhile pointing out where they are not
+   >   binary?
+   > - Can we say a few words about what the purpose of the "Name" column is?
+   > 
+   > 2.1.1
+   > - aspect -> aspects
+   > 
+   > 2.2.1.3
+   > 
+   > Based on the narrative of this section it's still not clear to me why
+   > we need to identify an instance of relation. It's not technical, nor
+   > critical to the release for LC.
+   > 
+   > 2.3 
+   > 
+   > - rewording of "All components specify extended structures,
+   > whereas only the first three define core structures."? To me, these
+   > components are used to express the core and extended structures, not
+   > to define these structures.
+   > 
+   > 5.1
+   > 
+   > - Figure 5 and many others (6, 7) do not fit into a page when
+   >   printed. Is easy to scale them down for this purpose, if not losing
+   >   the quality?
+   > 
+   > 5.1.6
+   > - have valid -> be valid
+   > 
+   > 5.3.5
+   > 
+   > - The example of in this section does not quite help me: 1) I don't
+   >   think W3C should be attributed to the DM document, but our editors;
+   >   unless I understand attribution wrong; and 2) can we have an example
+   >   to show that influence must be used, and cannot be replaced by any
+   >   other concepts. In my opinion such an example is key to illustrate
+   >   the purpose of this concept.
+   > 
+   > 5.4.1
+   > 
+   > - I don't understand the "There may be other kinds of bundles not
+   >   directly expressible by this constructor, such as napkin,
+   >   whiteboard, etc." How are they being bundles?
+   > 
+   > 5.5.3
+   > 
+   > - The narratives in this section are rather complex. But I am not
+   >   going into details because it's marked as at risk at the moment.
+   > 
+   > 5.6.
+   > 
+   > I like the new collection section, much lighter to read.
+   > 
+   > That's all! It's still not a short document, but it's much readable
+   > after these many rounds of revisions. So, well done!
+   > 
+   > -- Jun
+   > 
+   > 
+   > 
+   > ----------------------------------------------------------------------
+   > 
+   > Hi Luc,
+   > 
+   > My relies inline ...  > > It should print OK, and it does for me here.
+   > > Which browser are you using?
+   > 
+   > Chrome on Mac
+   > 
+   > >> 5.3.5 - The example of in this section does not quite help me: 1) I
+   > >> don't think W3C should be attributed to the DM document, but our
+   > >> editors; unless I understand attribution wrong; and 2) can we have
+   > >> an example to show that influence must be used, and cannot be
+   > >> replaced by any other concepts. In my opinion such an example is
+   > >> key to illustrate the purpose of this concept.
+   > 
+   > [...]
+   > 
+   > > Regarding your second point, I don't think it is possible. But I may
+   > > be wrong.
+   > 
+   > We have an example of prov:tracedTo in the prov-o, which should have
+   > been replaced with the new prov:wasInfluencedBy. Does that one help
+   > you?
+   > 
+   > > > > 5.5.3 > - The narratives in this section are rather complex. But
+   > >I am not > going into details because it's marked as at risk at the
+   > >moment.  > Can you help us by identifying what you find
+   > >complex. What's the first stumbling block for you (and the second
+   > >...)
+   > 
+   > I should have been more specific in my initial feedback.
+   > 
+   > It started with the definition of Mention: The mention ◊ of an entity
+   > in a bundle (containing a description of this entity) is another
+   > entity that is a specialization of the former and that presents the
+   > bundle as a further additional aspect.
+   > 
+   > In my opinion, this definition is trying to say too much in one
+   > sentence. Without any understanding about what this concept is for, I
+   > can't quite understand the specialization relationships between
+   > entities outlined here.
+   > 
+   > What I have in mind when thinking about this concept is something like
+   > the below:
+   > 
+   > "An entity can be mentioned in a bundle, which contains some
+   > descriptions about this entity. In this case, this entity in the
+   > bundle can be regarded as a specialization of another entity."
+   > 
+   > I don't want to go into too many detailed discussions about Mention. I
+   > am sure many other people have proposed some much more thought-through
+   > proposals than mine.
+   > 
+   > I am just trying to show how I think a more gentle introduction about
+   > the concept could help me, at least. The problem I have is that I
+   > don't know how to be more precise about this "another entity" because
+   > I don't know precisely what this another entity should
+   > be. Could/should it be something not in any bundles or something in
+   > another bundle? I felt difficult to say. Actually I could be
+   > equivalently happy with just the first part of the sentence.:) But I
+   > might be taking a too simplistic point of view of the problem.
+   > 
+   > I can provide more feedback if you want to pick up discussions on
+   > Mention again at a later, more appropriate time. But I have no
+   > objection to release the current draft as LC as long as this feature
+   > is marked as at risk.
+   > 
+   > HTH,
+   > 
+   > Jun
+   > 
+   > 
+   > 
+   > 
+   > 
+   > > > 5.6.  > > I like the new collection section, much lighter to read.
+   > >> > That's all! It's still not a short document, but it's much
+   > >readable > after these many rounds of revisions. So, well done!  > >
+   > >-- Jun > Luc > >
+   > 
+   > 
+   > 
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-437-satya.txt	Mon Jul 09 08:20:15 2012 +0100
@@ -0,0 +1,138 @@
+   > Hi,
+   > Kudos to both the editors, the current draft is very readable and well-structured!
+   > 
+   > >>Question for reviewers: Can the document be published as Last Call working draft?
+   > Yes. 
+   > 
+   > Thanks.
+   > 
+   > Best,
+   > Satya
+   > 
+   > Detailed review comments are as follows:
+   > ==============
+   > Section 2.1.1
+   > 
+   > 1. Rewrite sentence "Just as entities cover a broad range of notions,
+   > activities can cover a broad range of notions: information processing
+   > activities may for example move, copy, or duplicate digital entities;
+   > physical activities can include driving a car from Boston to
+   > Cambridge."  >>
+   > 
+   > "Just as entities cover a broad range of notions, activities can cover
+   > a broad range of notions: information processing activities and
+   > physical activities."
+   > 
+   > As Example 2 already describes the information processing activity and
+   > driving of car from Boston to Cambridge.
+   > 
+   > 2. Example 5 is not clear - is this in context of UK news - phone
+   > tapping issue (it is very country specific)
+   > 
+   > Section 5.1.6
+   > 1. Start: By defining all the attributes except Activity (being
+   > started) as optional leads to potentially confusing scenarios. If only
+   > the "time" attribute is used, e.g. wasStartedBy(a1, -, -,
+   > 2011-11-16T16:05:00), then instead of wasStartedBy, wasStartedAt (or
+   > some similar construct) needs to be used. Hence, suggest that
+   > "trigger" should not be optional since if the trigger is not known
+   > then it is more appropriate for the user or application to define/use
+   > a more relevant construct wasStartedAt (for time), wasInformedBy (if
+   > "starter" activity is known).
+   > 
+   > Section 5.1.7
+   > 1. Similar to above comment about wasStartedBy - "trigger" should not
+   > be optional. If the user/application does not have information about
+   > the trigger then the wasEndedBy construct should not be used and
+   > alternatively wasEndedAt, wasInformedBy should be used.
+   > 
+   > Section 5.1.8
+   > 
+   > The two example assertions in Example 27 are also confusing:
+   > wasGeneratedBy (ex:bbcNews2012-04-03, -, 2012-04-03T00:00:01) should
+   > be wasGeneratedAt if the activity that generated it is not
+   > known. Since the entity "bbcNews2012-04-03" was clearly not generated
+   > by time "2012-04-03T00:00:01"
+   > 
+   > wasInvalidatedBy(ex:bbcNews2012-04-03, -, 2012-04-03T23:59:59) should be wasInvalidatedAt
+   > 
+   > In example 28:
+   > 
+   > wasInvalidatedBy(buy_one_beer_get_one_free_offer_during_happy_hour,
+   > -,2012-03-10T18:00:00) should be wasInvalidatedAt
+   > 
+   > Section 5.3.5
+   > 1. The document should give a clear/concrete example of the use of
+   > Influence (in querying?). Since the document recommends use of
+   > specific "sub-types" of influence, the motivation or use of Influence
+   > is not clear in current description.
+   > 
+   > Section 5.4.1
+   > 1. The requirement for defining "Bundle Constructor" is not clear - is
+   > it similar to a class constructor used in object oriented programming?
+   > The relevance of such a construct in DM is not clear.
+   > 
+   > Section 5.4.2
+   > 1. Suggest that in example 39, the assertion
+   > wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01) should either have
+   > an "activity" or renamed to wasGeneratedAt
+   > 
+   > Section 5.5.1
+   > 1. The use of the statement "In particular, the lifetime of the entity
+   > being specialized contains that of any specialization." is not clear?
+   > Is it used in any constraint?
+   > 
+   > 2. Suggest using an alternate example for specialization, since
+   > "bbc:news/" will be a folder and "ex:bbcNews2012-03-23" will be a file
+   > within that folder (as web directories are structured)?
+   > Alternative example: 
+   > specializationOf(ex:W3CLastCallWorkingDraft, ex:W3CWorkingDraft)  
+   > 
+   > Section 5.5.2
+   > 1. It is a bit difficult to understand Example 44:
+   > alternateOf(tr:WD-prov-dm-20111018,tr:WD-prov-dm-20111215)
+   > 
+   > We also have wasDerivedFrom(tr:WD-prov-dm-20111018,tr:WD-prov-dm-20111215)
+   > 
+   > Since, there is not correlation between wasDerivedFrom and alternateOf
+   > (as far as I know), suggest removing Example 44.
+   > 
+   > Section 5.6
+   > 
+   > 1. According to the current description of Collection - "Some
+   > applications need to be able to express the provenance of the
+   > collection itself: e.g. who maintains the collection (attribution),
+   > which members it contains as it evolves, and how it was assembled.",
+   > Collection seems to be a specialization Bundle (for describing
+   > provenance of provenance).
+   > 
+   > ================
+   >  
+   > 
+   > 
+   > On Thu, Jun 28, 2012 at 5:55 PM, Provenance Working Group Issue
+   > Tracker <[email protected]> wrote:
+   > 
+   >     PROV-ISSUE-437 (prov-dm-post-f2f3-review): Final review before last call vote [prov-dm]
+   > 
+   >     http://www.w3.org/2011/prov/track/issues/437
+   > 
+   >     Raised by: Luc Moreau
+   >     On product: prov-dm
+   > 
+   > 
+   >     This is the issue to collect feedback on the prov-dm document (version created after F2F3)
+   > 
+   >     Document to review is available from:
+   > 
+   >     http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120628/prov-dm.html
+   > 
+   >     Question for reviewers: Can the document be published as Last Call working draft?
+   > 
+   >     Cheers,
+   >     Luc
+   > 
+   > 
+   > 
+   > 
+   >