--- a/model/comments/issue-331-graham.txt Tue Apr 10 21:59:28 2012 +0100
+++ b/model/comments/issue-331-graham.txt Wed Apr 11 09:05:02 2012 +0100
@@ -49,6 +49,7 @@
> like "Properties that link entities that are based on the same thing".
This questions the definition of specialization that was agreed over email.
+See ISSUE-29 discussion.
>
> "collections of entities, whose provenance itself can be tracked" - this feels
@@ -280,6 +281,13 @@
> I think this exhibits poor organization of the material. I think Agents and
> Plans are related, and suggest a sub-section for them. Collections and accounts
> don't have any obvious relationship, and IMO should be separated.
+
+All are types of entities, from this point of view it's logical.
+We can instead take the 'component 2 approach' in which we
+merge agent, plan, attribution, association, responsibility.
+
+
+
>
> Concerning collections, it is not at all clear to me that these need to be in
> the core PROV-DM. By including them here, you impose a particular view of
@@ -288,15 +296,25 @@
> that deal with collections have their own models for these, so why not let this
> be an aspect for domain-specific extension?
>
+
+To be discussed in WG.
+
>
> I think accounts should have a section of their own, since they underpin the key
> feature of supporting provenance0-of-provenance.
+
+To be addresse later.
+An option is to drop completely the notion of account from all our documents.
+
>
> However, I have a problem with the description "An account is an entity that
> contains a bundle of provenance descriptions." I think that this should be "An
> account *is* an entity that is a bundle of provenance descriptions." That is, I
> don't think the core DM needs to or should expose the notion of containment,
> since that begs more questions.
+
+But then, why should bundle be part of dm?
+
>
> == 2.4 Attribution, association and responsibility ==
>
@@ -318,6 +336,19 @@
> I can't see a software agent as being accountable. I don't know how to make
> sense of this, so it's hard for me to suggest alternatives.
>
+
+Does renaming the relation "Responsibility/actedOnBehalfOf" help?
+And also remove the word accountable?
+
+Should we go for responsi
+ Main Entry: delegation [del-i-gey-shuhn] Show IPA
+ Part of Speech: noun
+ Definition: assignment of responsibility
+ Synonyms: appointment, apportioning, authorization, charge, commissioning, committal, consigning, consignment, conveyance, conveying, deputation, deputization, deputizing, devolution, entrustment, giving over, installation, investiture, mandate, nomination, ordination, reference, referring, relegation, sending away, submittal, submitting, transferal, transference, transferring, trust
+ Notes: a delegation differs from a legation in that the members of a delegation are usually not charged with a specific mission but merely with the overall task of representing the interests of a body of people, often at a conference during an assembly's regular session; a legate usually acts alone while a delegate acts as part of a group
+ Antonyms: keeping
+
+
> == Section 2.5, Simplified overview diagram ==
> == Section 2.6, PROV-N ... ==
>
@@ -325,6 +356,10 @@
> I don't really think they belong here.
>
> I'd move them to start start of section 4.
+
+Will be an Editor's decision.
+
+
>
> == Section 3, Illustration... ==
>
@@ -338,17 +373,28 @@
>
> The enumeration of components seems to be repetitive. Numbered items *and*
> component numbers? (See earlier comment.)
+
+<ul> instead of <ol>
+
>
> "In the first column, one finds concept names directly linking to their English
> definition. In the second column, ...". Why not just use column headings in the
> table? The reference to "English" description seems redundant.
>
+
+Yes, to do.
+
+<hr><td>Concept or Relation Name </td><td>representation in the PROV-N notation</td></hr>
+
> "In the rest of the section, each concept and relation is defined, in English
> initially, followed by a more formal definition and some example." Similar
> comment. Suggest:
> "In the rest of the section, each type and relation is defined informally,
> followed by a summary of the information used to represent the concept, and
> illustrated with PROV-N examples."
+
+Good, in particular, it's type not concept.
+
>
> == 4.1.1 Entity ==
>
@@ -358,12 +404,21 @@
> "An entity is a thing one wants to provide provenance for. It can be physical,
> digital, conceptual, or otherwise, and may be real or imaginary."
>
+
+Use simon's definition.
+
> "An entity, written entity(id, [attr1=val1, ...]) in PROV-N, contains:" - I
> think this is wrong - an entity does not (in general) *contain*. Suggest:
> "An entity, written entity(id, [attr1=val1, ...]) in PROV-N, has:"
>
+OK
+
> "id: an identifier for an entity;" - this is redundant and potentially
> confusing. Suggest "id: an identifier".
+
+
+?????????
+
>
> "attributes: an optional set of attribute-value pairs ((attr1, val1), ...)
> representing this entity's situation in the world." - I find this phrasing
@@ -371,6 +426,11 @@
> "attributes: an optional set of attribute-value pairs ((attr1, val1), ...)
> representing additional nformation about this entity."
>
+
+
+OK, still legacy. UPdate attributes everywhere.
+
+
> == 4.1.2, et seq ==
>
> (Similar editorial comments to those for 4.1.1 Entity. I'm not repeating them
@@ -384,17 +444,26 @@
> "trigger: an optional identifier (e) for the entity triggering the activity;" -
> do you really mean to allow *any* entity here, rather than just agents?
>
+
+Yes: http://www.w3.org/2011/prov/meeting/2012-03-15#resolution_3
+
> Looking forward to the example, I find the idea that an email (qua entity) can
> "trigger" an activity is incoherent. Suppose the email is drafted and never
> sent. It still exists as an entity, but can't be said to actually *trigger*
> anything. For me, it is the act of actually sending (or receiving) an email
> that may trigger something, not the email as a passive entity.
>
+
+This may be expressed by start by activity, instead.
+
>
> == Section 4.1.6, End ==
>
> (Similar comments to those above.)
>
+
+http://www.w3.org/2011/prov/meeting/2012-03-15#resolution_3
+
>
> == Section 4.1.7, Communication ==
>
@@ -402,6 +471,12 @@
> that the communicated entity cannot be optionally named. I find myself
> wondering if I've understood the definition properly.
>
+
+In that case, one would just write.
+wasGeneratedBy(e,a1)
+used(a2,e)
+One doesn't need a new construct.
+
>
> == Section 4.2.1, Agent ==
>
@@ -410,6 +485,9 @@
>
> Awkward and unnecessary phrase "situation in the world" again. See earlier for
> suggested phrasing.
+
+situation in the world to check everywhere.
+
>
>
> == Section 4.3.1 Derivation ==
@@ -419,6 +497,11 @@
> seems ungrammatical. Suggest:
> "A derivation is a transformation of an entity into another, a construction of
> an entity *from* another, or an update of an entity, resulting in a new one."
+
+
+yes, to look into. It would be nice to keep the same directionality for all of them.
+
+
>
>
> == Section 4.5 Collections ==
@@ -439,18 +522,27 @@
> associated inference that I am aware of, and additional information can be added
> via attributes, so I'm not seeing what useful additional expressive capability
> this affords.
+
+I don't think it can be added with attributes, that's the whole point, since
+attributes and annotations can be added at different moments!
+
>
>
> == Section 4.7.4 Attribute ==
>
> Is an attribute really just a qualified name, or is it a pair consisting of a
> qualified name and a value?
+
+yes, a qualifed name.
>
>
> == Section 5, Extensibility points ==
>
> This section makes little sense to me. The obvious extensibility points of
> sub-typing and sub-properties of defined PROV-DM terms isn't mentioned.
+
+It's item 4.
+
>
> The use of new attributes seems reasonable, though it's not entirely clear how
> they act as extension points, and the mention of "perspective on the world"
@@ -459,6 +551,9 @@
> I cannot see how notes, which are defined to be pretty much semantics-free, can
> be described as an extensibility point - they don't actually add any expressive
> power that I can see.
+
+non prov-attributes are also semantics free (from prov perspective).
+
>
> The remaining points I just don't get.
>
@@ -466,11 +561,21 @@
> and comprehensively if it is to be taken seriously. Otherwise expect developers
> to ignore this and just use extensibility options in the representation
> substrate (e.g. RDF) used.
+
+
+Probably needs some updating.
+
+
>
> == Section 6 ==
>
> I think this section is completely redundant and out-of-place, and could be
> removed without any loss.
+
+I think there is some value in stating there is an other document to
+look at, and outline what it tackles.
+
+
>
>
> =================