Re: SQL delimited vs regular identifiers

David,

SQL identifiers are used in R2RML in four different contexts:

   1. rr:sqlQuery => SQL query
          * SQL rule: If user wants case-sensitivity of (or use of space
            etc. in) an identifier in a SQL query, s/he must use a
            delimited identifier (i.e., enclosed within double-quotes)
          * value of rr:sqlQuery follows this rule as well
   2. rr:tableName => schema-qualified table or view name
          * R2RML requires that each SQL identifier must be delimited if
            case-sensitivity is desired
          * Examples
                o SQL delimited identifier "my table" => rr:tableName
                  "\"my table\""
                o SQL regular identifier my_table => rr:tableName "my_table"
                o SQL delimited identifiers "scott" and "my table" =>
                  rr:tableName "\"scott\".\"my table\""
                o NOTE: if user specifies rr:tableName "my table" that
                  will be INVALID because the following is not a valid
                  SQL regular identifier: my table
   3. rr:template => column name(s) embedded in a string
          * R2RML requires that each SQL identifier must be delimited if
            case-sensitivity is desired
          * Examples
                o SQL delimited column identifiers "first name" and
                  "last name" => rr:template "my email address is
                  {\"first name\"}.{\"last name\"}@example.org"
                o SQL delimited column identifiers "FIRST NAME" and
                  "LAST NAME" => rr:template "my email address is
                  {\"FIRST NAME\"}.{\"LAST NAME\"}@example.org"
                o SQL regular column identifiers first_name and
                  last_name => rr:template "my email address is
                  {first_name}.{last_name}@example.org"
                o NOTE that rr:template "...{first name}.{last name}
                  ..."  will be INVALID
   4. rr:column => single column name
          * R2RML requires use of SQL delimited column identifiers if
            case-sensitivity is desired
          * Examples
                o SQL column identifier "full name" => rr:column "\"full
                  name\""
                o SQL delimited column identifier "FULL NAME" =>
                  rr:column "\"FULL NAME\""
                o SQL regular column identifier full_name => rr:column
                  "full_name"
                o NOTE that rr:column "full name" will be INVALID

The note in section 5 differs in the following way for case 3 and case 4 
above:

    * Case 3: any column identifier used in rr:template is considered a
      delimited identifier (thus avoids need for \" just following the
      opening brace ('{') or just preceding the closing brace ('}')
          o Example
                + SQL delimited column identifiers "first name" and
                  "last name" => rr:template "my email address is {first
                  name}.{last name}@example.org"
                + SQL delimited column identifiers "FIRST NAME" and
                  "LAST NAME" => rr:template "my email address is {FIRST
                  NAME}.{LAST NAME}@example.org"
                + SQL regular column identifiers first_name and
                  last_name => rr:template "my email address is
                  {FIRST_NAME}.{LAST_NAME}@example.org"
    * Case 4: column identifier specified for rr:column is considered a
      delimited identifier (thus avoids need for  \" just following or
      preceding the double-quote used for delimiting the RDF plain
      literal term)
          o Examples
                + SQL delimited column identifier "full name" =>
                  rr:column "full name"
                + SQL delimited column identifier "FULL NAME" =>
                  rr:column "FULL NAME"
                + SQL regular column identifier full_name => rr:column
                  "FULL_NAME"

Unless there are any additional comments, I'll go ahead and fix the note 
to eliminate this difference.

Thanks,
- Souri.

David McNeil wrote:
> I have several comments/questions about this note in section 5 of the 
> R2RML draft [1]
>
> "Note that in R2RML, column name specified as an RDF plain literal 
> <http://www.w3.org/2001/sw/rdb2rdf/r2rml/#dfn-plain-literal> or within 
> curly braces, is considered a delimited SQL identifier."
>
> 1) My reading of this is that a column or table name in an R2RML 
> mapping, like:
> rr:column "age"
> would be interpreted as a delimited identifier: "age", as opposed to a 
> regular (un-quoted) identifier: age
>
> For the case where SQL identifiers in the database are regular 
> identifiers, this has the effect of making the identifiers used in the 
> mapping case sensitive by default (since a regular identifier of AGE 
> in the database would not match a delimited identifier of "age" from 
> the mapping). In my experience most SQL identifiers are regular 
> identifiers and users are accustomed to entering identifiers in a case 
> in-sensitive manner. So it seems to me that it would be more useful if 
> R2RML supported case in-sensitive identifier usage by default. This 
> could be accomplished by interpreting RDF plain literals as regular 
> identifiers.
>
> 2) It is not clear to me how this matches the resolution identified in 
> "ISSUE-35: Case sensitivity of SQL 
> identifiershttp://www.w3.org/2001/sw/rdb2rdf/track/issues/35" [2]
>
> 3) As far as I can tell this approach is not documented in the 
> normative parts of the spec.
>
> 4) Why does it call out "column name[s]", why not other SQL 
> identifiers embedded in R2RML?
>
> 5) How are users to enter a regular identifier as a SQL identifier in 
> R2RML?
>
> 6) Per the normative part of the spec, is the user expected to be able 
> to enter a delimited identifier as:
> rr:column "\"age\""
>   
>
> 7) The grammar of the note needs some work.
>
> I admit these are slippery ideas, so perhaps I am not analyzing it all 
> correctly.
>
> -David
>
> [1] http://www.w3.org/2001/sw/rdb2rdf/r2rml/#logical-tables
> [2] http://www.w3.org/2001/sw/rdb2rdf/track/issues/35