IMPORTANT: remaining issues for closing CR

All,

In order to prepare next week's telecon I try to summarise the state of the remaining issues for closing CR in the following, identifying proposals where available and asking the WG to come up with concrete proposals where this is not the case.


1. Implementability for tables w/o primary key 

+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0030.html 
+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0036.html
+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0019.html

PROPOSAL: In the DM spec, replace the following text:

[[
If the table has no primary key, the row node is a fresh blank node that is unique to this row.
]]

with this:

[[
If the table has no primary key, the row node is a blank node. Distinct blank nodes MUST be generated for rows with distinct column values. For duplicate rows with identical values, implementations SHOULD generate a fresh blank for each duplicate row (resulting in a non-lean RDF graph [RDF Semantics]). However, if the underlying database system does not provide any means to reliably differentiate among the rows, then implementations MAY re-use the same blank node for multiple duplicate rows (resulting in a lean RDF graph). Implementations SHOULD document and advertise their chosen behavior.
]]



2. XSD mapping for binary columns (xsd:hexBinary vs. xsd:base64Binary)

+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0020.html

PROPOSAL: Binary datatypes like BLOB and VARBINARY should be mapped to xsd:hexBinary instead of xsd:base64Binary.



3. DM cannot be implemented as an R2RML mapping (period encoding)

+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0021.html

--> NO PROPOSAL known



4. Fixing an omission in R2RML: syntax of blank node labels

+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0060.html

PROPOSAL: Change Section 11.2 of R2RML (http://www.w3.org/TR/2012/CR-r2rml-20120223/#generated-rdf-term) from:

[[
If the term type is rr:BlankNode: Return a blank node whose blank node identifier is the natural RDF lexical form corresponding to value.
]]

to:

[[
If the term type is rr:BlankNode: Return a blank node that is unique to the natural RDF lexical form corresponding to value.

NOTE: RDF syntaxes and RDF APIs generally represent blank nodes with blank node identifiers. But the characters allowed in blank node identifiers differ between syntaxes, and not all characters occurring in value may be allowed, so a bijective mapping function from values to valid blank node identifiers may be required. The details of this mapping function are implementation-dependent, and an R2RML processors may have to use different functions for different output syntaxes or access interfaces. Strings matching the regular expression [a-zA-Z_][a-zA-Z_0-9-]* are valid blank node identifiers in all W3C-recommended RDF syntaxes.
]]



5.  Using non-existing column in mapping 

+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0018.html


Section 6 of the R2RML spec (http://www.w3.org/TR/2012/CR-r2rml-20120223/#triples-map) states:

[[
The referenced columns of all term maps of a triples map (subject map, predicate maps, object maps, graph maps) MUST be column names that exist in the term map's logical table.
]]


PROPOSAL: Any referenced columns (that is, the columns mentioned in rr:column, rr:template, etc.) that don't exist in the rr:sqlQuery or table are treated simply as being NULL, rather than being considered an error. Perhaps the case could still be treated as a warning:

[[
Processors MAY warn mapping authors if a referenced column does not exist in the logical table.
]]



6. Unnamed columns in rr:sqlQuery 

+ http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012Apr/0017.html

Section 5.2 of the R2RML spec (http://www.w3.org/TR/2012/CR-r2rml-20120223/#r2rml-views) states:

[[
Any columns in the SELECT list derived by projecting an expression MUST be named.
]]


PROPOSAL: Above to be replaced with an informative note:

[[
Note: Any columns in the SELECT list derived by projecting an expression should be explicitly named because otherwise they cannot be referenced in the rest of the mapping.
]]





Cheers,
	   Michael

--
Dr. Michael Hausenblas, Research Fellow
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel.: +353 91 495730
WebID: http://sw-app.org/mic.xhtml#i

Received on Friday, 27 April 2012 12:19:46 UTC