Re: Minutes of 2011-03-15 telecon

* Michael Hausenblas <michael.hausenblas@deri.org> [2011-03-15 17:41+0000]
> All,
> The minutes of today's meeting are now available for review at [1].
> Thanks a lot for scribing, Richard!
> We've reviewed the open issues and actions: we've postponed ISSUE-9
> and ISSUE-32 for post-publication handling and closed ISSUE-22,
> ISSUE-24, ISSUE-31.
> 
> We agreed on the following:
> [[
> RESOLUTION: Both R2RML and DM address all open action till Fr 18
> March and report on the list
> ]]
> 
> This means in detail, that the following actions need to be done:
> Souri/Seema:
>  Last week we accepted ISSUE-26 [2] but I didn't find an action
> attached to it. Can you please check and take an action on this one?
> 
> Eric:
>  ACTION-105

Digging into issue 105, I saw that it was defined by issue 29, which
had to do with re-interpreting bnodes. Working from memory, I recall
that I promised to document how the SQL spec produces lexical casts.
Here's a bit of the documentation to help interested parties along:

Looking at ISO/IEC JTC 1/SC 32 2006-02-01 ('cause I don't have a more
recent spec), we can follow JTC 1's lead for mapping between different
ASTs (in this case, mapping from the SQL language to the XML language).

Section 9.5 "Mapping SQL data types to XML Schema data types" provides
a mapping from XSL datatypes to W3C XML Schema datatypes. I believe we
can just reference that and give a couple of obvious examples, like
INTEGER to xsd:integer.

Section 9.8 "Mapping values of SQL data types to values of XML Schema
data types" e.g. an SQL value in the SQL INTEGER domain to an SQL
string of type xsd:integer. As xsd:integer is defined in terms of
restrictions on a value interpreted from a unicode string, the SQL
spec produces that string via a cast. Given a value V and an
implementation-defined (!) maximum string length M, the lexical value
is obtained by:

for types with standard character representation (strings, date*):
  Implementation-defined mapping of V to unicode, making sure the
  target XML supports all the chars.

for numeric data types:
  "CAST (V AS CHARACTER VARYING(M) )"

boolean:
  LOWER(V)

That covers the XSD types discussed in SPARQL and elides SQL rows,
arrays and XML Literals.

I expect we're adequately specified if we say "an RDF Literal with the
datatype defined as XMLT in section 9.5 "Mapping SQL data types to XML
Schema data types" and a lexical value defined as XMLV in 9.8 "Mapping
values of SQL data types to values of XML Schema data types".


>  ACTION-110 (was ACTION-104 on Juan)

done


> Eric and Souri:
>  ACTION-107

Souri and I chased this down and decided that "default graph" was the
way to go because otherwise we'd have to say how the "unnamed graph"
was used in SPARQL. Simply waving the possibility of the latter in
front of the group produce popular outcry so it looks like we've
settled on "default graph".


> Richard:
>  ACTION-108
>  ACTION-109
> 
> Given we have all actions done, the WG can review both drafts at:
>   http://www.w3.org/2001/sw/rdb2rdf/directMapping/
>   http://www.w3.org/2001/sw/rdb2rdf/r2rml/
> and the proposal for next week's meeting is to publish these two ED
> as WD.
> 
> Cheers,
> 	Michael
> 
> [1] http://www.w3.org/2011/03/15-rdb2rdf-minutes.html
> [2] http://www.w3.org/2011/03/08-rdb2rdf-minutes.html#item07
> --
> Dr. Michael Hausenblas, Research Fellow
> LiDRC - Linked Data Research Centre
> DERI - Digital Enterprise Research Institute
> NUIG - National University of Ireland, Galway
> Ireland, Europe
> Tel. +353 91 495730
> http://linkeddata.deri.ie/
> http://sw-app.org/about.html
> 
> 

-- 
-ericP

Received on Thursday, 17 March 2011 23:17:51 UTC