Re: PROV-ISSUE-438 (prov-n-post-f2f3-review ): Final review before last call vote [prov-n]

Hi Stian,

Thanks for your review. I wanted to focus on technical issues in the 
grammar.
We will produce a detailed response to your review.

>> generationExpression    ::=    "wasGeneratedBy" "(" optionalIdentifier eIdentifier ( "," aIdentifierOrMarker "," timeOrMarker )? optionalAttributeValuePairs ")"
>>      
> This does not allow aIdentifierOrMarker without timeOrMarker - is this
> intentional?
>    


Yes, all optionals or none is the adopted convention.
>> 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 ")"
>>      
>    

You are right. This has been fixed.
>> 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.
>
>    


It is correct that 1337 can be a QUALIFIED_NAME and an
INT_LITERAL. The context allows us to disambiguate:
INT_LITERAL are only allowed as convenienceNotation for literals.

>    
>> 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.
>    

There is misunderstanding here. This note is exactly the point you made 
above.

The conflict is between INT_LITERAL and QUALIFIED_NAME, and not
QUALIFIED_NAME_LITERAL.




>
> 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.
>
>
>    

Agreed, this has to be done systematically.

> 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
>    


You are right. It was a mistake in the prov-n document. My reference
implementation has PN_PREFIX as  you suggest.

> 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
>
>    


No, this is not correct.
PN_PREFIX always has at least one character.

PN_PREFIX      ::=      PN_CHARS_BASE ((PN_CHARS|'.')* PN_CHARS)?

<QUALIFIED_NAME>       ::=       ( PN_PREFIX ":" )? PN_LOCAL | PN_PREFIX ":"

> 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
>
>
>    

So, there is no need to change the productions as you suggest.

>>   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.
>    

You are right, I forgot about this.

Should we say that %xx is to be expanded before making the URI?
Would it solve the problem?


>> 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
>
>    



I mean PN_PREFIX.


abc can be a PN_PREFIX or a QUALIFIED_NAME (PN_LOCAL only, no PN_PREFIX)




Luc

Received on Sunday, 8 July 2012 22:00:47 UTC