Re: Regrets for tomorrow's teleconf. and summary on DTB discussions.

Michael Kifer wrote:
> 1. Curie, <...>
> My main concern with context sensitivity is that it will confuse people
> (like it did several members of this group) to think that the stuff after
> ^^ are constants by themselves. This requires that we explain things
> carefully and, possibly, will cause more confusion. The more context
> sensitivity we have, the more explaining we have to do, and no amount of
> explanation might be enough.
> 
> My strong preference is to limit context sensitivity or completely
> eliminate it, but in the spirit of reconciliation I am also willing to go
> with majority :-)
> 
> By the way, I did not understand what PNAME_LN and PNAME_NS are. I guessed
> that the latter is the foo:bar thingie, but what is LN?

see the resepctive productions at
http://www.w3.org/TR/rdf-sparql-query/#rPrefixedName
http://www.w3.org/TR/rdf-sparql-query/#rPNAME_LN
http://www.w3.org/TR/rdf-sparql-query/#rPNAME_NS

> 2. PREFIX.
> I do not like the syntax PREFIX(...), since it suggests that this is a
> fact-formula.

If it causes ambiguity then we need to change it, indeed.

> However, I am ok with it as a directive (with the same syntax
> as you suggest) in the preamble of the document, along with Import and
> whatever else we'll end up having there. 

fine for me.

> 3. Regarding your response to Hassan suggesting &quot; instead of \", I do
> not understand your reasoning. You were so gang-ho on brevity and now
> suddenly 6 characters instead of two?
> 
> If you want to use entities, like &quot;, then why not use them
> throughout? That is, instead of rif:iri use &rif;iri, and we are done away
> with context-sensitive curies and all that. (This is what I was proposing
> from the very beginning except that I was suggesting to use : instead of
> &...;.)

Probably, you, Sandro, and Hassan are right that XML entities in the 
presentation syntax are confusing. Alternatively, escape sequences like 
defined in SPARQL seem to be better:
http://www.w3.org/TR/rdf-sparql-query/#grammarEscapes
http://www.w3.org/TR/rdf-sparql-query/#codepointEscape

Does that look more reasonable to you?

I agree that we should focus on the XML syntax issues now as suggested 
in Sandro's mail. But I guess the SPARQL escaping mechanism should do 
for the moment... I assume hey spent some thinking on it and in case 
there are problems, we can revisit this point upon feedback.

best,
Axel

> 	--michael  
> 
>> Sorry, this might be unconvenient, but due to an urgent meeting whch I 
>> cannot shift, I have to pass on tomorrow's telephone conference.
>>
>> So, in order not to hamper progress for DTB, I suggested several options 
>> to vote over concerning the points in my mail at [1].
>>
>> http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0194.html
>>
>> 1) CURIEs: As for 1) there were extensive discussions on the 
>> mailinglists, it seems that [2] is kind of a minimalistic proposal 
>> whereas [3] is richer. I haven't seen a grammar for [2] yet, so let me 
>> put both options on the table again.
>>
>> a), cf. [3]
>>
>>    ANGLEBRACKIRI     ::= '<' IRIRef '>'
>>
>>    STRING            ::= '"' ANYSTRINGWITHOUTQUOTES '"'
>>
>>    CURIE                ::=  PNAME_LN | PNAME_NS
>>
>>    Const             ::= ANGLEBRACKIRI
>>                        | CURIE
>>                        | STRING^^ANGLEBRACKIRI
>>                        | STRING^^CURIE
>>
>> b), cf. [2]
>>
>>    ANGLEBRACKIRI     ::= '<' IRIRef '>'
>>
>>    STRING            ::= '"' ANYSTRINGWITHOUTQUOTES '"'
>>
>>    CURIE                ::=  PNAME_LN | PNAME_NS
>>
>>    Const             ::=  CURIE
>>                        |  STRING^^ANGLEBRACKIRI
>>                        |  STRING^^CURIE
>>
>>
>> Comparison between a) and b): The only difference is that b) doesn't 
>> allow ANGLEBRACKIRIs as Consts, thus making it N3 incompatible, but 
>> well. Both are context-sensitive. There were some other discussions 
>> introducing some form of "aliasing" [2,4], but since I didn't see a 
>> grammar for this and thus it is unclear whether these would introduce 
>> ambiguity,  I suggest to keep it out.
>>
>> I suggest to vote between these two, my own vote is for a), though I am 
>> willing to obey a majority vote for b). I personally would be unhappy 
>> with N3 incompatibility [5,6] when voted for b), since none of the 
>> arguments given so far were technical in the sense of that there would 
>> be any problem with the grammar for a). For an additional argument, see 
>> also 4) below.
>>
>> 2) FULL URIs for RIF (see also [7])
>>
>>  From the original proposals, the following 2 seem to have "survived" 
>> the discussions so far:
>>
>> a) define own prefixes (separate for functions and predicates):
>>
>>   http://www.w3.org/2007/rif-builtin-predicates#numeric-equal
>>
>>   http://www.w3.org/2007/rif-builtin-functions#concat
>>
>> c) reuse XPath/Xquery fn: prefix (problem: not prefix defined for op: we 
>> still would need to invent one):
>>
>>   http://www.w3.org/2005/xpath-??????#numeric-equal
>>
>>   http://www.w3.org/2005/xpath-functions#concat
>>
>> I personally prefer a) and suggest to
>>
>> PROPOSE: We define own namespace prefixes
>>    PREFIX("pred", "http://www.w3.org/2007/rif-builtin-predicates#").
>>    PREFIX("func", "http://www.w3.org/2007/rif-builtin-functions#").
>> for RIF builtin functions and predicates
>>
>>
>> 3) The handling of errors seems not to be anything we need to discuss 
>> over again.
>>
>> 4) Additionally, I suggest to introduce:
>>
>>    PREFIXDef         ::= ' PREFIX(' PNAME_LN , STRING ') .'
>>
>> for the prefix definition in the presentation syntax.
>> Whether this expands to Qnames or entitties in the actual XMLificaiton 
>> is a separate issues [8,9] and not important for stabilitzing DTB, it 
>> seems. In doubt, I am with Michael here [9] and suggest that in a 
>> translator to XML PREFIXDef translates to an ENTITY definition... but 
>> that's an implementation detail anyways, one could likewise simply 
>> expand all CURIEs in the XML.... The only problem with that is that if 
>> you want to translate *BACK* to presentation syntax again, you will end 
>> up with something ugly, if we go for option b) on 1) above.
>>
>>
>> Axel
>>
>>
>>
>> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0194.html
>>
>> [2] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0015.html
>>
>> [3] http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0203.html
>>
>> [4] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0019.html
>>
>> [5] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0005.html
>>
>> [6] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0008.html
>>
>> [7] http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0196.html
>>
>> [8] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0011.html
>>      and following thread.
>>
>> [9] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0027.html
>>
>>
> 


-- 
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

rdfs:Resource owl:differentFrom xsd:anyURI .

Received on Tuesday, 6 May 2008 07:29:00 UTC