--- /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 <sysbot+tracker@w3.org> 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
+ >
+ >
+ >
+ >
+ >