W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > November 2011

ENCODE_FOR_LOCAL_NAME

From: David Booth <david@dbooth.org>
Date: Mon, 07 Nov 2011 21:33:24 -0500
To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
Message-ID: <1320719604.30661.41270.camel@dbooth-laptop>
It would be helpful if SPARQL would define an ENCODE_FOR_LOCAL_NAME
function.

At present, SPARQL provides the ENCODE_FOR_URI function to facilitate
the generation of new URIs within SPARQL queries or updates.  This is
helpful, however often one needs to generate a new URI with a fixed
prefix and variable local name part, so that the generated URIs can be
used conveniently in subsequent SPARQL, Turtle and RDF/XML contexts.
But because the syntactic restrictions for local names (in SPARQL,
Turtle and XML) are more stringent than for URIs in general, additional
encoding is required.

For example, in

  PREFIX ex: <http://example/>
  . . . 
  BIND(uri(concat(str(ex:), encode_for_uri("Frankfurt"))) AS ?city)

?city becomes <http://example/Frankfurt>, which can be conveniently
written as:

  ex:Frankfurt

But if instead we have

  BIND(uri(concat(str(ex:), encode_for_uri("Los Angeles"))) AS ?city)

then encode_for_uri returns "Los%20Angeles", so ?city becomes

  <http://example/Los%20Angeles>

which cannot be written as

  ex:Los%20Angeles

because "%" is forbidden in a local name.  However, 

  encode_for_local_name("Los Angeles")

would instead return a more stringently escaped string that would be
guaranteed legal in a local name.  For example, it could return
"Los_P20Angeles" (having "%" further encoded as "_P").  There are many
ways this encoding could be done; this is just one example.  Ideally the
SPARQL spec should pick one particular way as the standard (or the
default).

I do not expect the working group to be able to address this for the
current release of SPARQL, but I would be grateful if it could be placed
on a wish list for the next version.

Thanks!

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Tuesday, 8 November 2011 02:33:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 November 2011 02:34:00 GMT