W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2008

Re: CURIE proposal ... (was: Re: [DTB] ACTIONs 428 and 292 completed)

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 21 Apr 2008 20:41:13 -0400
To: Axel Polleres <axel.polleres@deri.org>
Cc: Chris Welty <cawelty@gmail.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>, Michael Kifer <kifer@cs.sunysb.edu>
Message-ID: <17179.1208824873@ubuhebe>


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

Indeed.

> 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:
                                      Turtle  :-)
> 
> 
> "mailto:chris"^^rif:iri
         this uses the mailto uri scheme
> vs
> mailto:chris^^rif:iri
         this is a CURIE using some prefix "mailto"
> vs.
> <mailto:chris>
         this uses the mailto uri scheme, exactle same as option 1
> vs.
> mailto:chris^^<rif:iri>
         this is an error (not detectable by RIF), since there's no
         "rif" uri scheme, right? 

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

I'm happy with this approach.   I think the spec text could probably be
a bit simpler, but I don't have better text to suggest right now.

     -- Sandro

> Axel
> 
> >  >
> >  >> See, for example, Example 2 in
> >  >> http://www.w3.org/2005/rules/wiki/BLD#EBNF_for_the_RIF-BLD_Rule_Languag
> e
> >  >
> >  >
> >  >
> >  >> 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 Tuesday, 22 April 2008 00:42:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:48 GMT