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

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.


	--michael  


> 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 12:12:14 UTC