--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-438-khalid.txt Sun Jul 08 21:40:34 2012 +0100
@@ -0,0 +1,83 @@
+ >
+ > Hi,
+ >
+ > Generally, the document reads well and is quite concise which I think is good.
+ > Below are few comments.
+ >
+ > - The notion of Topbundle is put forward in few places as the top
+ > level non terminal expression. I am not sure if that serves a
+ > purpose, specially that a top level bundle may, I imagine, be
+ > references by other non terminal expressions, e.g., wasAttributedTo.
+ >
+ > - For the reader to understand Example 2, we may need to add a few
+ > words to say what a, g2 and u1 represent, which can be done in one
+ > sentence I think. For example, "where a is the activity the used e1
+ > to generate e2. u1 and g2 represents the usage and generation,
+ > respectively."
+ >
+ > - In Section 2.5: "cooments" -> "comments"
+ >
+ > - In Section, 3.1.2, I suspect that "time" is non terminal, and
+ > therefore, the reader may expect it to be broken down into terminals
+ > terms. I know this is beyond the scope of PROV-DM, but it would be
+ > good to add a sentence saying that.
+ >
+ > - There are two terms that are used to define identfiers: "Identifier"
+ > and "OptionalIdentifier". Why not use "Identifier" and when it is
+ > optional use "(Identifier)?" as specified in Section 2.2?
+ >
+ > - In section 3.1.4, it is said that "Even though the production
+ > usageExpression allows for expressions used(a2, -, -) and used(-;
+ > e2, -, -), these expressions are not valid in PROV-N, since at least
+ > one of id, entity, time, and attributes must be present." However,
+ > according to the definition of Usage in [12], the activity
+ > identifier is not optional.
+ >
+ > - Section 3.2.1, defines derivation as: [17] derivationExpression ::=
+ > "wasDerivedFrom" "(" optionalIdentifier eIdentifier "," eIdentifier (
+ > "," aIdentifierOrMarker "," gIdentifierOrMarker ","
+ > uIdentifierOrMarker )? optionalAttributeValuePairs ")"
+ >
+ > I may be wrong, but the ( "," aIdentifierOrMarker ","
+ > gIdentifierOrMarker "," uIdentifierOrMarker )? means that either all
+ > of the terms activity, generation and usage are present or none of
+ > them. In other words, the above definition may need to be altered to
+ > something like:
+ >
+ > derivationExpression ::= "wasDerivedFrom" "(" optionalIdentifier
+ > eIdentifier "," eIdentifier ( "," aIdentifierOrMarker)? (","
+ > gIdentifierOrMarker ")? (," uIdentifierOrMarker )?
+ > optionalAttributeValuePairs ")"
+ >
+ > - Looking at the definition of Revision, Quotation and Primary source,
+ > I am wondering if it would make sense to say something about the
+ > kind of derivation in the derivationExpression, to state that it may
+ > contain an additional optional element that specifies the kind of
+ > derivation.
+ >
+ > Khalid
+ >
+ > On 14 June 2012 12:07, Provenance Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
+ >
+ > PROV-ISSUE-408 (prov-n-review-for-LC): feedback on PROV-N document (for last call release) [prov-n]
+ >
+ > http://www.w3.org/2011/prov/track/issues/408
+ >
+ > Raised by: Luc Moreau
+ > On product: prov-n
+ >
+ >
+ > This is the issue to collect feedback on prov-n document.
+ >
+ > Document to review is available from:
+ >
+ > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-n-20120614/prov-n.html
+ >
+ > Question for reviewers: http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.06.14
+ >
+ > Cheers,
+ > Luc
+ >
+
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/issue-438-stian.txt Sun Jul 08 21:40:34 2012 +0100
@@ -0,0 +1,658 @@
+ > On Fri, Jun 29, 2012 at 1:23 PM, Provenance Working Group Issue
+ > Tracker <sysbot+tracker@w3.org> wrote:
+ > > > PROV-ISSUE-438 (prov-n-post-f2f3-review ): Final review before last call vote [prov-n]
+ > > > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-n-20120629/prov-n.html
+ > > >
+ > > > Question for reviewers: Can the document be published as Last Call working draft?
+ >
+ > Of my comments below, the following SHOULD be addressed before
+ > publishing as Last Call draft:
+ > * introduce "nonterminal"
+ > * fix syntax errors
+ > * memberOf -> hasMember
+ > * clarify/remote % encoding in local part of QUALIFIED_NAME
+ > * clarifications about namespace scoping/overwrite
+ >
+ > Given a minimum of the above are addressed, then yes, the document can
+ > be published as Last Call WD.
+ >
+ > Loads of details follow.. don't despair!
+ >
+ >
+ > ===================================
+ >
+ >
+ >
+ >
+ >
+ > In 1.1, the use of the term "nonterminal" is not introduced. This
+ > computer science term used for parsers might be obvious for anyone who
+ > is reading the document to produce a PROV-N parser, but not for
+ > "Readers of the [PROV-DM] and of [PROV-CONSTRAINTS] documents". I see
+ > the term is used several times later in the document, and so should be
+ > introduced.
+ >
+ > A sentence like "Those readers may find the _expression_ nonterminal a
+ > useful entry point into the grammar" should be reformulated to
+ > something like "Those readers may find the definition _expression_ a
+ > useful entry point into the grammar".
+ >
+ >
+ >
+ >
+ > > > 1.3 The PROV namespace (see Section 4.7.1)
+ > The section number should be 3.7.4
+ >
+ >
+ > > > 2.1
+ > > > All PROV data model relations involve two primary elements, the subject and the object, in this order
+ > Not true. Examples:
+ >
+ > > > activity(a1)
+ > > > entity(e1)
+ > So those might not be 'relations' - but that is not clear from the
+ > above. Rephrase to something like "Many PROV-N predicates denote a
+ > relationship between two primary elements, the _subject_ and the
+ > _object_, in this order".
+ >
+ > I would include an entity() example in this section, to show that not
+ > all have subject and object. I would do this before Example 1 and the
+ > above sentence.
+ >
+ > > > Example 0:
+ > > > In this example, _e1_ is asserted to be a PROV _entity_.
+ > > > entity(e1)
+ >
+ >
+ > > > Example 2
+ > > > In the following expressions, the optional activity a along with the generation and usage identifiers g2 and u1:
+ > > > wasDerivedFrom(e2, e1, a, g2, u1)
+ > The sentence does not parse. I suggest "The following expression
+ > expands the above derivation relation by providing additional
+ > elements: the activity _a_, the generation _g2_ and the usage _u1_.
+ >
+ > > > Extended Backus-Naur Form (EBNF) notation
+ > This is again well known in CS - but a hyperlink would be useful. Now
+ > I had to go to Wikipedia. However the mini-intro right below is
+ > useful. "The below is a summary of "
+ >
+ >
+ > I would be more precise, that "The PROV-N grammar is specified in this
+ > document using the .." - as knowledge of EBNF is not a requirement for
+ > using PROV-N - just for understanding the definitions in this
+ > document.
+ >
+ >
+ >
+ > > > 2.2 EBNF Grammar
+ > > > ..
+ > > > Each expression non-terminal expression i.e., entityExpression, activityExpression etc., corresponds to
+ > expression non-terminal expression??
+ >
+ >
+ > Reformulate to something like "Each of the symbols included in
+ > _expression_ above, e.g. entityExpression, corresponds to one element
+ > (e.g. entity) in the PROV data model."
+ >
+ >
+ > Why hyperlinks on 'expression' here in this section? It goes 1 line up
+ > or down, it's very confusing. Use <code>expression</code> or similar
+ > instead.
+ >
+ >
+ > > > such that the text for an element matches the corresponding expression production of the grammar.
+ > What does this mean? That the text of the document corresponds to what
+ > you get by parsing the text? That does not tell me anything..
+ >
+ >
+ > Is the bundle construct now required for the PROV-N document? If so,
+ > almost none of the examples in this document or in PROV-DM are valid
+ > PROV-N documents. That might well be the case, as they want to reuse
+ > namespaces, etc - but that should then be stated explicitly, kind of
+ > like
+ >
+ >
+ > > > 2.3 Optional attributes
+ > Should add something like "The interpretation of an optional attribute
+ > that is not provided is given by Section 4.1 in PROV-CONSTRAINTS"
+ > somewhere.
+ >
+ >
+ > > > 2.4 Identifiers and attributes
+ >
+ > > > Most expressions defined in the grammar include the use of two
+ > terms: an identifier and a set of attribute-value pairs, delimited
+ > by square brackets
+ > This reads like:
+ >
+ > > > identifier [] attribute-value pairs
+ > Which is not what is meant! Something more like:
+ >
+ > "Almost all expressions defined in this grammar may also include an
+ > identifier for the expression. Most expression can also include a set
+ > of attribute-value pairs, grouped within square brackets."
+ >
+ >
+ > "By convention, optional identifiers are separated using a semi-colon
+ > ';'." By convention.. but I might do something else? Just say that
+ > they ARE separated like that: "Optional identifiers are separated
+ > using a semi-colon ';', but where the identifiers are required, the
+ > regular comma ',' is used."
+ >
+ > Or do you say I need to also allow parsing with ',' for the
+ > permutations that are non-ambigious? The defition for
+ > optionalIdentifier says no. (good!)
+ >
+ >
+ > > > Example 7
+ > > > ..
+ > > > The third example shows that one can optionally indicate the missing identifier using the - marker.
+ > Add "This is equivalent to the first expression".
+ >
+ > > > Example 8
+ > > > The first and second activities have no attributes.
+ > Add ", and are equivalent."
+ >
+ >
+ > > > 2.5 Comments
+ > > > ... such cooments ...
+ > "such comments"
+ >
+ >
+ > > > 3.1.3 Generation
+ > > > generationExpression ::= "wasGeneratedBy" "(" optionalIdentifier
+ > eIdentifier ( "," aIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"
+ > This does not allow aIdentifierOrMarker without timeOrMarker - is this
+ > intentional?
+ >
+ >
+ > The following examples are not valid:
+ >
+ > > > wasGeneratedBy(e2, a1, tr:WD-prov-dm-20111215)
+ > > > wasGeneratedBy(ex:g1; e, a, tr:WD-prov-dm-20111215)
+ > because tr:WD-prov-dm-20111215 is not a valid timeOrMarker.
+ >
+ >
+ > I would also recommend that these show-cases use the same names, so
+ > rather than say intermixing a1 and ex:edit1 - just always use a1.
+ >
+ >
+ > > > > > > Even though the production generationExpression allows for expressions wasGeneratedBy(e2, -, -) and > wasGeneratedBy(-; e2, -, -),
+ > these expressions are not valid in PROV-N, since at least one of id, activity, time, and attributes must be present.
+ > This is suboptimal, could it not be worked into the rules in time?
+ > Could we rather say this follows from PROV-CONSTRAINTS and PROV-DM?
+ > "Since" does not make sense here - where is it stated that they MUST
+ > be present? Here. So try rather: "... are not valid in PROV-N; at
+ > least one of... MUST be present"
+ >
+ > Equivalent comment for this kind of paragraph for usage, startExpression, etc.
+ >
+ >
+ >
+ > > > 3.1.4 Usage
+ > usageExpression ::= "used" "(" optionalIdentifier aIdentifier
+ > "," ( "," eIdentifierOrMarker "," timeOrMarker )?
+ > optionalAttributeValuePairs ")"
+ >
+ > This wrongly requires a double comma before
+ > eIdentifierOrMarker-timeormarker block:
+ >
+ > used(a1,,e,-)
+ >
+ > Should be:
+ >
+ > > > usageExpression ::= "used" "(" optionalIdentifier aIdentifier ( "," eIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"
+ >
+ > This rule also requires timeOrMarker if eIdentifierOrMarker is present
+ > - is this intentional? I won't ask this again for the following forms
+ > - but assume that the style is "no optionals or all optionals" - in
+ > which case this should be clarified in section 2.3 - the position
+ > argument hints that the old style of allowing to chop of trailing -'s
+ > is allowed.
+ >
+ > > > Even though the production usageExpression allows for expressions used(a2, -, -) and used(-; e2, -, -),
+ > should be:
+ > used(-; a1, -, -)
+ >
+ > > > 3.1.6 Start
+ > > > Note: Even though the production startExpression allows for expressions wasStartedBy(e2, -, -) and wasStartedBy(-; > e2, -, -),
+ > Should be:
+ > wasStartedBy(a1, -, -, -)
+ > wasStartedBy(-; a1, -, -, -)
+ >
+ >
+ > > > 3.1.7 End
+ > > > wasEndedBy(e; ex:act2)
+ > > > wasEndedBy(e; ex:act2, ex:trigger, -, 2011-11-16T16:00:00)
+ > I would not use 'e' as id here - that is confusing as 'e' is used for
+ > entity earlier. Try 'end'.
+ >
+ > > > Note:Even though the production endExpression allows for expressions wasEndedBy(e2, -, -) and wasEndedBy(-; e2, -, -),
+ > Should be:
+ > wasEndedBy(a1, -, -, -)
+ > wasEndedBy(-; a1, -, -, -),
+ >
+ >
+ > 3.2.1 Derivation
+ >
+ > The following examples are invalid:
+ >
+ > wasDerivedFrom(d, e2, e1, a, g2, u1, [ex:comment="a righteous derivation"])
+ > wasDerivedFrom(d, e2, e1, a, g2, u1)
+ > wasDerivedFrom(-, e2, e1, a, g2, u1)
+ >
+ > As they should use ; to terminate optionalIdentifier rather than ,
+ >
+ >
+ >
+ > 3.3.2 -> 3.2.4 (Revision, Quotation, Primary Source)
+ >
+ > An introduction on the top of these should be provided, to note that
+ > the regular syntax for wasDerivedFrom is used, with the additional
+ > prov:type attribute given to specify the type of derivation. As it
+ > stands it can read as if only the syntax used in the example is valid.
+ > Make these subsections of 3.2.1 instead?
+ >
+ >
+ > 3.2.4
+ > > > [ prove:type='prov:PrimarySource' ])
+ > Should be:
+ >
+ > [ prov:type='prov:PrimarySource' ])
+ >
+ >
+ > The use of 'single quotes' for the prov:type as opposed to "double
+ > quote" for the other attribute is confusing. By reading deeply into
+ > section 3.7.3 I see this is a short hand for "ex:value" %%
+ > prov:QUALIFIED_NAME. Could a link be provided for this in 3.2.x?
+ >
+ > prov:type is not explained anywhere in PROV-N. Almost all examples
+ > using it with custom attributes use "double quotes", for instance:
+ >
+ > > actedOnBehalfOf(del1; ag2, ag1, a, [prov:type="contract"])
+ >
+ > > agent(ag4, [ prov:type="prov:Person", ex:name="David" ])
+ >
+ > I assumed (wrongly?) that prov:type in a way has range
+ > prov:QUALIFIED_NAME union xsd:anyURI - but I'm not sure as "a Literal
+ > may be an IRI-typed string (with datatype xsd:anyURI); such IRI has no
+ > specific interpretation in the context of PROV.".
+ >
+ > So does prov:type="contract" simply mean "contract" out of thin air
+ > rather than bound to any namespace? We would struggle to translate
+ > this to PROV-O where prov:type maps to rdf:type. If this is the case,
+ > then I expect all prov:type="prov.*" should be with single quotes
+ > instead.
+ >
+ >
+ > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120628/prov-dm.html#term-attribute-type
+ > says "PROV-DM is agnostic about the representation of types, and only
+ > states that the value associated with a prov:type attribute must be a
+ > PROV-DM Value." - but does not distinguish between 'single', "double"
+ > quote and "qualified" %% prov:QUALIFIED_NAME notation.
+ >
+ >
+ >
+ > > > 3.4.1 Bundle declaration
+ > > > Example 26
+ > > > bundle ex:author-view
+ > > > agent(ex:Paolo, [ prov:type='prov:Person' ])
+ > > > agent(ex:Simon, [ prov:type='prov:Person' ])
+ > > > ...
+ > > > endBundle
+ > Nitpicking, but I would use " // ... " as "..." is not valid PROV-N.
+ >
+ >
+ > 3.4.1 should also provide a forward link to 4. Toplevel Bundle,
+ > because otherwise the example does not make sense (prefix ex: is not
+ > declared)
+ >
+ >
+ >
+ >
+ > > > 3.5.3 Mention
+ > > > mentionExpression ::= "mentionOf" "(" identifier "," identifier "," bIdentifier ")"
+ > Should be:
+ >
+ > mentionExpression ::= "mentionOf" "(" eIdentifier ","
+ > eIdentifier "," bIdentifier ")"
+ >
+ >
+ >
+ >
+ > 3.6.1 Membership
+ >
+ > > > memberOf(mId, c, {e1, e2, e3}, []) // Collection membership
+ > should be:
+ >
+ > > > memberOf(mId; c, {e1, e2, e3}, []) // Collection membership
+ >
+ >
+ > This reads the wrong way - it says c is a member of {e1, e2, e3} by
+ > the previously mentioned subject-relation-object rule.
+ >
+ > Propose renaming 'memberOf' to 'hasMembers', 'hadMembers' or
+ > 'members'. (I do not propose to make the entity or entity set as first
+ > argument)
+ >
+ >
+ > Opposite of all other example, this example does not start with a
+ > 'full' expression, as the 'complete' argument is missing. Also the
+ > attributes are empty. I would change to:
+ >
+ >
+ > memberOf(mId; c, {e1, e2, e3}, true, [dct:description="All of them"])
+ > // Collection membership
+ >
+ >
+ > > > // default "complete" flag is false
+ > This is a PROV-DM or PROV-CONSTRAINT matter and should not be
+ > described here - the remaining relations don't explain meaning of
+ > missing optionals.
+ >
+ >
+ > > > memberOf(c3, ,[])
+ > > > memberOf(c3, ,true, [])
+ > Invalid syntax, as entitySet ::= "{" (eIdentifier)* "}"
+ >
+ > Change to:
+ >
+ > memberOf(c3, {} ,[])
+ > memberOf(c3, {} ,true, [])
+ >
+ > First one of these should be invalid by the same reason as for usage,
+ > and thus should not be listed. (It would need to include some
+ > attributes in [] to be valid)
+ >
+ >
+ > 3.7.1 Identifier
+ >
+ > > > dIdentifier ::= identifier
+ >
+ > This is not used anywhere and can be removed. (Dictionary?)
+ >
+ >
+ > A qualified name's prefix is optional. If a prefix occurs in a qualified name,
+ > it refers to a namespace declared in a namespace declaration.
+ > I would change it to "it MUST refer to a namespace as declared in a.."
+ > - otherwise this would be valid:
+ >
+ > bundle
+ > prefix ex <http://example.com/>
+ > entity(fred:e1)
+ > endBundle
+ >
+ > without declaring the prefix "fred".
+ >
+ >
+ >
+ >
+ > > > 3.7.2 Attribute
+ > > > The reserved attributes in the PROV namespace are the following.
+ > add "Their meaning is explained by [PROV-DM]".
+ >
+ >
+ > <INT_LITERAL> ::= ("-")? (DIGIT)+
+ >
+ > This *might* be in conflict with QUALIFIED_NAME which allows local
+ > names like "1337" (without quotes) - but I have not checked so
+ > thoroughly. It is at least confusing. It means that you can do:
+ >
+ > entity(1337, [1337=1337])
+ >
+ > where the first and second 1337 is the relative IRI reference <1337>
+ > based on the default namespace, while the third 1337 is the number
+ > "1337" %% xsd:int.
+ >
+ > However I don't think there is anywhere that allows both a literal and
+ > an identifier in the same position, so we MIGHT be safe. Parser heads
+ > converge here.
+ >
+ >
+ > > > 3.7.3 Literal
+ > Note:The productions for prov:QUALIFIED_NAME and INT_LITERAL are conflicting. In the context of a literal,
+ > a parser should give precedence to the production for INT_LITERAL.
+ > Again, I don't see this conflict, as the former requires 'single'
+ > quotes and the latter does not allow that.
+ >
+ >
+ > entity(e1, [ex:value='1337']) // equivalent to
+ > entity(e1, [ex:value="1337" %% prov:QUALIFIED_NAME])
+ >
+ > entity(e1, [ex:value=1337]) // equivalent to
+ > entity(e1, [ex:value="1337" %% xsd:int])
+ >
+ >
+ > It would be good if a (separate) example in 3.7.3 showed all of these
+ > equivalences.
+ >
+ >
+ >
+ > > > 3.7.3.1 Reserved Type Values
+ > > > The reserved type values in the PROV namespace are the following
+ > Add "Their meaning is defined by [PROV-DM].
+ >
+ >
+ >
+ >
+ >
+ > 3.7.4 Namespace
+ >
+ >
+ > > > namespaceDeclaration ::= "prefix" QUALIFIED_NAME namespace
+ > > > <QUALIFIED_NAME> ::= ( PN_PREFIX ":" )? PN_LOCAL
+ > > > | PN_PREFIX ":"
+ > This would allow:
+ >
+ > bundle
+ > prefix fred:soup <http://example.com/>
+ > endBundle
+ >
+ > but all the examples define prefix with only the lefthand side of a
+ > QUALIFIED_NAME - ie. PN_PREFIX. So it should be:
+ >
+ >
+ > namespaceDeclaration ::= "prefix" PN_PREFIX namespace
+ >
+ > To match all valid prefixes in QUALIFIED_NAME.
+ >
+ > Note that QUALIFIED_NAME allows the empty prefix, ie ":ex1" (which is
+ > different from "ex1"). ((And thus also ":"))
+ >
+ > However this would be difficult to declare ":" in the current prefix
+ > rule, because unlike say in Sparql and Turtle, the prefix is not
+ > declared with the trailing ":". One would have to say:
+ >
+ > bundle
+ > prefix <http://example.com/> // Two spaces before < !
+ > endBundle
+ >
+ >
+ > I suggest to change the prefix declaration to include the trailing : - ie:
+ >
+ > namespaceDeclaration ::= "prefix" QUALIFIED_NAME ":" namespace
+ > bundle
+ > prefix : <http://example.com/>
+ > prefix ex: <http://www.example.org/>
+ > endBundle
+ >
+ >
+ > > > Instead, they can be %-escaped or incorporated in the IRI denoted by a prefix.
+ > > > <PERCENT> ::= "%" HEX HEX
+ > It is not defined what is the meaning of this escaping. What do the
+ > HEX represent? If you mean "as in section 3.1. Mapping of IRIs to
+ > URIs of [RFC3987]" - then include this.
+ >
+ > Should be "in corporated in *a* namespace URI denoted by a prefix" -
+ > as presumably that specific namespace binding does not exist yet if
+ > you needed special characters in the local name.
+ >
+ > I'm still not sure what this mean.
+ >
+ > Assume you have:
+ >
+ > bundle
+ > prefix s11: <http://s11.no/>
+ > // ...
+ > endBundle
+ >
+ > And in there, you want to refer to the entity for
+ > <http://s11.no/?fred=soup>. Then presumably I could do:
+ >
+ > entity(s11:?fred%3Dsoup)
+ >
+ > but only if we intend for %xx to be expanded before making the URI,
+ > rather than, as suggested by PROV-N, simply be valid parts of the URI
+ > by concatenation.
+ >
+ > If we say they are passed on directly - then I don't see a way to
+ > represent the above, as %3d escape for = is valid argument in query
+ > parameters - such as in ?q=1%2B1%3D2 (1+1=2) - and thus %3Dsoup not
+ > understood as the original =soup.
+ >
+ > Note - I am not arguing for double-escaping here, as I think that
+ > would become very confusing - I am just wondering why % was added here
+ > in the first place, if still only a selection of possibly local names
+ > (given a general prefix) is valid - I think it just adds potential
+ > complexity.
+ >
+ > Of course the reason why this happens is because we don't have a
+ > <URIREF> syntax allowed together with QUALIFIED_NAME - so the Sparql
+ > analogy breaks down.
+ >
+ >
+ > > > entity(ex:1234) // corresponds to IRI http://example.org/2/1234
+ > should be
+ >
+ > entity(ex:1234) // corresponds to IRI http://example.org/1/1234
+ >
+ >
+ > I would add:
+ >
+ > entity(c/) // corresponds to IRI http://example.org/2/c/
+ > entity(ex:/) // corresponds to IRI http://example.org/1// //
+ > Strict concatenation
+ >
+ >
+ >
+ > What does the following mean?
+ >
+ >
+ > Note:The productions for qualifiedName and prefix are conflicting. In
+ > the context of a namespaceDeclaration, a parser should give precedence
+ > to the production for prefix.
+ >
+ > With 'prefix' here - do you mean PN_PREFIX or the keyword 'prefix' within
+ >
+ > > > namespaceDeclaration ::= "prefix" QUALIFIED_NAME namespace
+ > ?
+ >
+ > I still don't see any conflict. namespaceDeclaration requires the word
+ > 'prefix', and so the following should be valid:
+ >
+ > bundle
+ > prefix
+ > prefix
+ > <prefix>
+ > endBundle
+ >
+ > ie. binding the prefix "prefix:" to the relative IRI reference <prefix>.
+ >
+ > namespaceDeclarations is optional in both bundle and namedBundle - but
+ > "prefix" is not a valid expression, and can thus I don't see any
+ > conflict here.
+ >
+ >
+ >
+ > 3.7.4 does not define how to interpret re-declaration of the same prefix:
+ >
+ > bundle
+ > prefix ex1 <http://example.org/1/>
+ > prefix ex1 <http://example.org/2/>
+ > entity(ex1:fred)
+ > endBundle
+ >
+ > (Personally I think they should not be allowed - Turtle will overwrite
+ > sequentially - but nothing else in PROV-N depends on the sequence)
+ >
+ >
+ > 3.7.4 does neither not define that that prefixes and defaults are
+ > looked up in the named bundle before the top level bundle.
+ >
+ > bundle
+ > default <http://example.com/>
+ > entity(fred)
+ > bundle fred // same fred
+ > default <http://www.example.org/>
+ > entity(fred) // Different fred!
+ > endBundle
+ > endBundle
+ >
+ >
+ > > > Section 4
+ > > > A toplevel bundle, written _bundle decls exprs bundles endBundle_ in PROV-N, contains:
+ > This 'written' thing is very confusing, as it is not written like
+ > that. I would move up the bundle production rule first - use the same
+ > style as for all the other productions. The following "Contains"
+ > bullet points also only make sense after seeing the production rule:
+ >
+ > > > bundle ::= "bundle" (namespaceDeclarations)? (expression)* (namedBundle)* "endBundle"
+ > The bullet points are confusing, because they talk about decls and
+ > exprs vs namespaceDeclarations and expressions. Only one variable
+ > name, please!
+ >
+ >
+ > namespaceDeclarations are optional - both here and in the named
+ > bundle. This means that this would be valid:
+ >
+ > bundle
+ > entity(e1) // What is the default namespace??
+ > bundle b1
+ > // or what is it here?
+ > entity(e2)
+ > endBundle
+ > endBundle
+ >
+ >
+ > I found it confusing that the top level bundle and named bundle have
+ > the same keyword. However I expect - although it is not stated
+ > explicitly here - that you can't have a free-standing named bundle -
+ > and that a PROV-N Document should have all expressions and named
+ > bundled within a single top level bundle.
+ >
+ >
+ > > > activity(a1, 2011-11-16T16:05:00, -,[prov:type="edit"])
+ > Should be (pretty printed ;) )
+ >
+ > activity(a1, 2011-11-16T16:05:00, -, [prov:type="edit"])
+ >
+ >
+ > > > The following container
+ > > > (..)
+ > > > This container
+ > s/container/bundle/g
+ >
+ >
+ >
+ >
+ > > > 5. Media Type
+ > We agreed some changes to this in the telcon 2012-07-05,
+ > "text/provenance-notation" and ".provn".
+ >
+ > > > Published specification:
+ > > > This specification.
+ > In the actual submission I assume that this will rather refer to /tr/PROV-N/.
+ >
+ >
+ > > > may have the strings 'bundle' near the beginning
+ > s/strings/string/
+ >
+ >
+ > > > Section B
+ > I did not review section A or B in detail.
+ >
+ > Some whitespace needed after 'Cheney' both for [PROV-XML] and [PROV-RDF]
+ >
+ >
+ > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
+ >