- From: Axel Polleres <axel.polleres@deri.org>
- Date: Tue, 22 Apr 2008 00:25:50 +0100
- To: Chris Welty <cawelty@gmail.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
- CC: Michael Kifer <kifer@cs.sunysb.edu>
Chris Welty wrote: [...] > > Michael Kifer wrote: > >> One more comment. All names of the builtins must belong to some symbol > >> space. So, the proper naming would be something like > >> > >> "pred:isLong"^^rif:iri > >> > >> rather than pred:isLong. > > > > The first sentence in the namespace section explains that this is > > exactly how I use prefixed abbreviations here. The long version is > > highly unreadable. > > While I think we all agree that they are unreadable, keep in mind that > people > will very likely be cutting&pasting from your document, so a comment > buried in > the introduction will easily be missed. I suggest using the full syntax and > we'll try to fix the problem universally. > > -Chris I was starting to expand the IRIs as advised... so far only upto Section 4.2 of http://www.w3.org/2005/rules/wiki/DTB Before I waste more time with something which probably need to revise, let me try to make the universal proposal you seem to ask for, first: Let me remark, that we have an ambiguity/problem already in BLD with our sloppy definitions and "informal" use of CURIEs: "For brevity, we use the compact URI notation [CURIE], prefix:suffix, which should be understood as a macro that expands into a concatenation of the prefix definition and suffix. Thus, if bks is a prefix that expands into http://example.com/books# then bks:LeRif should be understood merely as an abbreviation for http://example.com/books#LeRif. The compact URI notation is not part of the RIF-BLD syntax." I think that this is ambiguous, given that CURIEs are not syntactically different from IRIRefs here. let us ilustrate this by the following simple example... "mailto:chris"^^rif:iri now, is mailto:chris a CURIE now or an IRI? I would rather suggest the following: 1) We use UNQUOTED prefix:ncname to denote CURIEs which expand to QUOTED IRIs 2) Anything in quotes can NOT be expanded. 3) For "IRI"^^rif:iri we also allow to write <IRI> 4) For symbol space IRIs (i.e. IRIs after the ^^) we only allow eithr the unquoted prefix:ncname writing or the angle bracketted name. ( 5) optionally, in the presentation syntax we drop rif:iri completely and ONLY allow the < > notation for iris.) That would bring us fairly close to Turlte: "mailto:chris"^^rif:iri vs mailto:chris^^rif:iri vs. <mailto:chris> vs. mailto:chris^^<rif:iri> are 3 different constants where the 2nd and the 3rd are syntactic sugar. In whole, I suggest to replace the aove paragraph with the following: ------------------------------------------------------------------------ For brevity, we use the compact URI notation [CURIE], <tt>prefix:suffix</tt>, which should be understood as a macro that expands into a concatenation of the prefix definition and suffix whenever not appearing within quotes or angle brackets. We use angle brackets to denote full IRIs. Note that for symbol spaces only IRIs are allowed. Thus, if bks is a prefix that expands into http://example.com/books# then bks:LeRif should be understood merely as an abbreviation for "http://example.com/books#LeRif"^^rif:iri, which - in turn - is an appreviation for "http://example.com/books#LeRif"^^<http://www.w3.org/2007/rif#iri> As syntactic sugar, we allow to simply write <IRI> for constants in the rif:iri symbol space, i.e. for our example we could even shorter write: <http://example.com/books#LeRif> The compact URI notation is part of the RIF presentation syntax. Where we allow to define namespace prefixes following the syntax of [SPARQL http://www.w3.org/TR/rdf-sparql-query/#rPrefixDecl] i.e. prefix bks: <http://example.com/books#> The EBNF grammar for prefix declarations is: PrefixDecl ::= 'PREFIX' PN_PREFIX? ':' IRI_REF IRI_REF ::= '<' ([^<>"{}|^`\]-[#x00-#x20])* '>' PN_PREFIX ::= PN_CHARS_BASE ((PN_CHARS|'.')* PN_CHARS)? PN_CHARS ::= PN_CHARS_U | '-' | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] PN_CHARS_U ::= PN_CHARS_BASE | '_' PN_CHARS_BASE ::= [A-Z] | [a-z] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x02FF] | [#x0370-#x037D] | [#x037F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] ------------------------------------------------------------------------ This proposal solves several problems we have now, I think the definition is no longer recursive, and I'd hope that it is acceptable... Axel > > > >> See, for example, Example 2 in > >> http://www.w3.org/2005/rules/wiki/BLD#EBNF_for_the_RIF-BLD_Rule_Language > > > > > > > >> Alternatively, we could allocate a separate symbol space to the > >> builtins. In this case, they would look something like > > > > I did suggest separatee symbol spaces some time ago in an ealier mail, > > resp it was like that on the syntax proposals... with the addition that > > - if we have a separate symbol space - why then do we need a keyword > > "External"? > > If we had separate symbol spaces, I think this sufficiently designates > > builtins syntactically. > > > >> "isLong"^^rif:predicate > >> > >> --michael > >>> DTB is ready for review, slightly delayed: > >>> > >>> http://www.w3.org/2005/rules/wiki/DTB > >>> > >>> At least, it should be - although not officially part of the > >>> published working drafts in this round - be stablilized to comply > >>> mostly with the definitions in FLD and BLD concerning external schemas. > >>> > >>> This also completes ACTION-292 > >>> "Put links for each builtin to Xquery source URI" > >>> > >>> best, > >>> Axel > > > > > > -- > Dr. Christopher A. Welty IBM Watson Research Center > +1.914.784.7055 19 Skyline Dr. > cawelty@gmail.com Hawthorne, NY 10532 > http://www.research.ibm.com/people/w/welty > -- 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 Monday, 21 April 2008 23:26:35 UTC