--- a/model/comments-from-graham.txt Fri Jul 29 10:28:01 2011 +0100
+++ b/model/comments-from-graham.txt Fri Jul 29 12:16:38 2011 +0100
@@ -24,20 +24,65 @@
>
> For a general audience, examples based on Unix command shell commands
> are probably not very helpful.
+
+LUC: We should probably talk about an attachment in an email, or a copy on a memory stick.
+
>
> What is "characterized entity represented by the file". As this is an
> example, just say "crime statistics" - would that be a correct
> interpretation?
+
+
+LUC: That's a presentational problem. In the example, we use the terminology introduced in section 4/5.
+
>
>
> 3.2 where did 'e0' come from? - it's not mentioned in 3.1. What is it intended to denote?
>
+
+LUC: correct.
+
> The "agent" statements are completely impenetrable to me.
>
> How is the notation to be interpreted. It looks a b it like some kind
> of deviant Prolog, but either I've forgotten some of the basic
> constructs, or it's not entirely clear how the deviant bits are meant
> to be interpreted.
+
+
+LUC:
+
+It's the BOB notation that it unclear. It feels we need to be more
+precise about it. This can go to the appendix.
+
+bob(id, [ type: "Person", name: "Edith" ])
+
+Further more, my choice of id, ag_al .... was a bit cryptic.
+
+So, why not go for e10, e11, e12, ....?
+
+
+A BNF like grammar for the abstract syntax notation
+
+<construct> :== <name> '(' <argument+> ')'
+<argument+> ::= <argument> | <argument> ',' <argument+>
+<argument> ::= <identifier>
+ | <role>
+ | <time>
+ | <properties>
+
+<properties> ::= [ <attribute-value*> ]
+<attribute-value*> ::= | <attribute-value> ',' <attribute-value*>
+<attribute-value> ::= <attribute> ':' <value>
+
+<value> ::= <string> | <number> | <time>
+
+
+<role> ::= token
+<identifier> ::= token
+<attributed> ::= token
+
+
>
>
> 3.3 graphical representation: could be very useful, and would be much
@@ -45,7 +90,10 @@
>
> What does it mean for an agent to be linked to a BOB as opposed to a
> process execution (cf. Alice and e0).
- >
+
+
+LUC: Yes, do we introduce pe0 or do we allow for agent to be linked to
+ bobs.
PROV-ISSUE-62
@@ -69,6 +117,10 @@
>
> Why "characterized entities" as opposed to perceived entities"?
> What's the important distinction here?
+
+LUC: let's replaced perceived (which occurs only once in the document)
+by characterized.
+
>
> The only interpretation I've found that makes sense to me is that the
> document is concerning itself with entities that are characterized by
@@ -76,6 +128,13 @@
> interpretation, if correct, is not obvious to me from the wording
> here.
>
+
+
+LUC: this sentence is over restricting. The document is not just
+concerned with characterized entities, but also activities, and how
+one "influences" the other.
+
+
>
> "PIL is a language by which representations of the world can be
> expressed using terms that are drawn from a controlled vocabulary. "
@@ -91,6 +150,12 @@
> "These representations are relative to the context of an asserter, and
> in that sense constitute perceptions about the world." which ties
> back to the earlier statement about "as perceived by their asserters".
+
+LUC: better to avoid the word context
+
+LUC: given that i suggested to replace perceived by characterized. No change required.
+
+
>
> "All assertions in PIL SHOULD be interpreted as a record of what has
> happened, as opposed to what may or will happen." I feel we should
@@ -102,6 +167,11 @@
> happen or potential observations." In this, I am using the reference
> to a context to provide just enough wiggle-room for description in
> future or imagined contexts.
+
+LUC: I am comfortable with SHOULD. Introducing MUST would disallow us to
+interpret assertions for reproducing/executing experiments. SHOULD opens
+the door for that. But we indicate clearly it's not our business here.
+
>
> "This specification does not prescribe the means by which assertions
> are made, for example on the basis of observations, inferences, or any
@@ -110,11 +180,19 @@
> confusing - I would think that assertions are made in PIL for the
> purposes of this spec. Suggest "... how assertions are arrived at,
> ..."
+
+LUC: the means by which asserters arrive at/formulate their assertions;
+
>
> "The language introduces a notion of "provenance container", which
> provides a default scope for assertions." The term "container" here
> is suggested of a physical or logical encapsulation, which I don't
> think is meant. How about "provenance context"?
+
+LUC: that's what is meant. That's the term in the charter. Please, no
+use of 'context'. At this stage, no action, we need to get to a
+definition of provenanceContainer.
+
>
> [[ ... The model may define additional scoping rules for
> assertions. Identifiers can safely be used within that
@@ -127,11 +205,20 @@
> defining linguistic constructs such as identifiers and scoping.
> Assuming the actual language used will be RDF, I'm not seeing how what
> you describe will be possible.
+
+LUC: mail sent to graham.
>
> "In this specification, when an assertion is defined to refer to
> another assertion about something, it does so by means of that thing's
> identifier." I don't understand what this is trying to say.
>
+
+LUC: In this specification, when we write "an assertion B
+<em>refers</em> to another assertion A about something", we mean that
+B contains that thing'sidentifier, as included in assertion A.
+
+
+
>
ISSUE-60
@@ -143,6 +230,13 @@
> What does it mean to not be "characterized"? If this refers to the
> attribute-based assertions mentioned earlier, does this mean that if
> there are no such assertions, an entity cannot be a "BOB"?
+
+LUC: Having written a comment about characterized entities in section 4,
+ now, he asks what we mean here?
+
+LUC: A BOB MAY not have any attribute listed. It's fine, and compatible with
+the idea that the list of attributes is not complete.
+
>
> [[ A BOB assertion is about a characterized entity, whose situation in
> the world is variant. A BOB assertion is made at a particular point
@@ -152,11 +246,17 @@
> This section is, according to its heading, about "BOB". But this is
> defining a different concept, so shouldn't this be in a separate
> section?
+
+LUC: Which different context?
+
>
> It seems to me that what we're talking about here is a "provenance
> assertion". I think it would be clearer to just describe that, e.g.
> [[ A provenance assertion is about an entity, whose situation in the
> world is generally assumed to be variable. ]]
+
+LUC: ???? Hello ???
+
>
> I either don't understand or don't agree with the second part of that
> description. The notion of assigning values as party of an assertion