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 .