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

Michael Kifer wrote:
>> 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
> 
> OK. Perhaps somebody can explain this a bit more? It looks like that syntax
> allows things like prefix: and abc...de.
> 
> 
>>> 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.
> 
> ok
> 
>>> 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?
> 
> SPARQL escapes? These look to me like good old C language escapes.
> These are fine, but do not assume that the world began with Sparql.

??? of course not.


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


-- 
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 13:41:35 UTC