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

Hi Stian,



On 07/09/2012 10:17 AM, Stian Soiland-Reyes wrote:
> On Sun, Jul 8, 2012 at 11:00 PM, Luc Moreau<L.Moreau@ecs.soton.ac.uk>  wrote:
>    
>>> 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.
>>      
> Well, there is still no 'precedence' unless you have a context-free
> parser (which would struggle more with the two 'bundle' variants), as
> there is no rules that permit both a literal and QUALIFIED_NAME.
> Literals are only valid for:
>
> attributeValuePair    ::=    attribute "=" literal
>
>
>    

But we do have a conflict, given that
1234 can be both a INT_LITERAL and a QUALIFIED_NAME

I am not sure what you are saying.

- Should we change the grammar and avoid conflict?
- Should the text  ' a parser should give precedence to the production  
INT_LITERAL' be changed?




>> No, this is not correct.
>> PN_PREFIX always has at least one character.
>>
>> PN_PREFIX      ::=      PN_CHARS_BASE ((PN_CHARS|'.')* PN_CHARS)?
>>      
> Ah, my fault. The hyperlink goes wrongly to
> http://www.w3.org/TR/rdf-sparql-query/#rPN_LOCAL rather than
> http://www.w3.org/TR/rdf-sparql-query/#rPN_PREFIX you see. (which also
> requires a first character - so I don't know why I got confused!)
>
>
>    
You're right, the link was wrong, it is now fixed.

>>> 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?
>>      
> No, I think it would get confusing.. If we are to double escape, then
> we should use a different character, like we do with %% instead of ^^
> for data types.
>
> IRI_REF   ::=   '<' ([^<>"{}|^`\]-[#x00-#x20])* '>'
>
> so IRI_REF does not allow ^ - so we could do the opposite in our rule
> for PN_LOCAL by adding "^" and say that it is to be expanded similar
> to % in URIs (as a byte sequence of UTF8) - but that this expansion
> will happen before concatenation to the full URL. Any % would just
> pass thru (this should also be clarified).
>
>
> Thus:
>
> http://example.com/?fred=fish%20soup can be expressed as:
>
> bundle
>    prefix ex<http://example.com/>
>    entity(ex:?fred^25fish%20soup)
> endBundle
>
> However I don't find that example very readable and against the
> motivation for PROV-N. I would not be advocating this suggestion
> strongly - I would argue for<IRI>  support rather than making our own
> "anything goes" CURIEs.
>
>
>
>    

I am reluctant to make such a change in the last hour, given that
we have always said identifiers are qualified names.


This said, your solution is actually supported indirectly, with the 
following

bundle
   prefix exfred<http://example.com/?fred=fish%20soup>
   entity(exfred:)
endBundle


Thoughts?

> Note that this syntax would also allow another way to get duplicate
> identifiers that are equal:
>
> bundle
>    prefix ex<http://example.com/>
>    entity(ex:fred)
>    entity(ex:fre^64)
>    entity(ex:^66red)
> endBundle
>
>
> It's not a big problem, as you can already do
>
> bundle
>    prefix ex<http://example.com/>
>    prefix exf<http://example.com/f>
>    prefix exfr<http://example.com/fr>
>    entity(ex:fred)
>    entity(exf:red)
>    entity(exfr:ed)
> endBundle
>
>
>
>    
>>>> 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)
>>      
> Within the context of a namespaceDeclaration - how can you get a PN_PREFIX?
>
>    
>> namespaceDeclaration    ::=    "prefix" QUALIFIED_NAME namespace
>>      
> 'precedence' implies that both could be valid.  Here it is in fact
> QUALIFIED_NAME that is required, not a PN_PREFIX.
>    

So to clarify, the correct production is

namespaceDeclaration    ::=    "prefix" PN_PREFIX namespace

Again, there is a conflict between PN_PREFIX and QUALIFIED_NAME.

abc can be both a PN_PREFIX and a QUALIFIED_NAME.

I don't see this  as an issue, as long as PN_PREFIX is preferred over 
QUALIFIED_NAME
in the context of the namespaceDeclaration.

What are you suggesting we do here?

Luc


>
>    

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Monday, 9 July 2012 09:49:21 UTC