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

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


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


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



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.


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Monday, 9 July 2012 09:18:52 UTC