<trackbot> Date: 10 May 2011

sure

<mhausenblas> scribenick: dmcneil

<mhausenblas> I hope both ericP and betehess can follow on IRC?

Admin

<mhausenblas> PROPOSAL: Accept the minutes of last meeting http://www.w3.org/2011/05/03-rdb2rdf-minutes.html

michael: start with accepting minutes of last meeting

RESOLUTION: working group approves minutes of last meeting

LC planning

<alexdeleon> sorry guys don't what's going on

ashok: question 1 about last call planning: when do we need to publish?

question 2: what does the status need to be in regard to the issues (do they all have to be closed)?

ivan maybe could talk us through the process

ivan: for last call the point is that all technical issues are closed

as soon as we reach that point we can publish LC (last call)

ashok: what if we discuss comments at TPAC

what is the latest we can publish

michael: we need to be in LC for a couple of weeks before TPAC in order to discuss the comments at TPAC (at our face-to-face meeting)

we can calculate back from there

<ericP> ivan,

ashok: if we tentatively agree to publish LC specs on or before Oct 1 that would give us a month

ivan: i think it would be better to have it earlier

suppose we receive a large number of LC comments

<mhausenblas> Michael: LC must at least last 3 weeks (http://www.w3.org/2005/10/Process-20051014/tr#last-call)

then we would need the time

the goal of the face-to-face should be to close all last call comments

so after face-to-face we can publish candidate recommendation

if there are many LC comments, there may be too many to resolve at face-to-face

so if we could publish LC on Sept 1, then we should be able to close everything at face-to-face

publich candidate recommendation in Nov

should not be ahuge problem to get implementations

then could propose final spec in Feb

michael: doc says LC period needs a minumum of 3 weeks

ivan: closing LC requires some administration

<mhausenblas> Michael:

<mhausenblas> [[Duration of the review: The announcement begins a review period that SHOULD last at least three weeks but MAY last longer if the technical report is complex or has significant external dependencies.]]

<mhausenblas> from http://www.w3.org/2005/10/Process-20051014/tr#last-call

michael: should we create a wiki page with the timeline and who should do what?

ashok: should ask working group if a last call on Sept 1 seems reasonable

michael: there are still open issues, "pending review", and "postponed" issues

so we would have 3 months to close all of these (+ any new ones)

there would be roughly 20+ issues to address

ashok: should try and speed up our rate a bit, but think it is possible

ivan: let's close some issues today :)

<cygri> let's clone some editors

ashok: i will create a wiki page of LC timeline

<mhausenblas> ACTION: Ashok to draft Wiki page with LC sprint time line with Sep 2011 LC [recorded in http://www.w3.org/2011/05/10-rdb2rdf-minutes.html#action01]

<trackbot> Created ACTION-125 - Draft Wiki page with LC sprint time line with Sep 2011 LC [on Ashok Malhotra - due 2011-05-17].

Action Items

michael: on to review action items

<mhausenblas> ACTION-122?

<trackbot> ACTION-122 -- Alexander de Leon to draft a proposal for ISSUE-18 -- due 2011-05-10 -- OPEN

<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/actions/122

<ivan> PROPOSAL: To resolve ISSUE-18 by always requiring use of a URI (or blank

<ivan> node) to identify the logical table to use for a TriplesMap and

<ivan> specifying the details about the logical table using either the pair of

<ivan> properties, rr:tableName and rr:tableOwner, or the property rr:SQLQuery.

<mhausenblas> http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011May/0023.html

ivan: souri sent out email with proposed names for the properties/classes

souri: I alligned the names with the "logical table" terminology from the R2RML spec

instead of the name "row source"

+q

souri: URI or blank node

dmcneil: asks about using the names rr:table to point to a resource of type Table or Query

souri: even though the current names are long, prefers them becuase the spec refers to logical tables

so it is clearer to have longer versions

cygri: given two proposals, I am always for shorter

understand concern about being precise, but think that at the end of the day people have to read/write this stuff

user needs to understand it once, but needs to read/write repeatedly

there is no risk of it being confused with another property

should be as short as possible as long as they are still unique

<Souri> David, What was the shorter name you were suggesting?

PROPOSAL: use a property named "table" to refer to a resource of type Table or Query

ted: if we are going to use a term of use in this document, then the first time we say "table" and mean "logical table" then we define it at that point

this maintains the brevity and the clarity

<mhausenblas> PROPOSAL: to resolve ISSUE-18 as proposed here: http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011May/0023.html with the change to use a property named "table" to refer to a resource of type Table or Query

<MacTed> quick rev...

<Souri> These are the names now: rr:logicalTable, rr:NamedLogicalTableClass, rr:QueryLogicalTableClass. What would be the new corr names?

<MacTed> at first use of "table" state that "in this doc, we use `table` to mean `logical table`"

<MacTed> or some such...

<scribe> new names would be rr:table rr:Table rr:Query

<Ashok> +1 to Ted's suggestion

alex: i like Table and Query, but we were putting Class at the end of all of the type names, will we keep this convention?

<Souri> so, rr:TableClass and rr:QueryClass?

souri: we have used that convention so far

cygri: why? because it is a class?

souri: yes

cygri: what about TriplesMap?

<Souri> http://www.w3.org/2001/sw/rdb2rdf/r2rml/#TriplesMapClass_Class

michael: if we are in agreement, and just about gettng the names right, can we leave that up to the editors? if the principle modeling is agreed

cygri: for consistency all the properties should have a Property suffix?

michael: gag

souri: I don't mind getting rid of the Class suffix, just should be consistent

michael: original proposal with an action for editors to come up with consistent naming for all classes

<mhausenblas> PROPOSAL: to resolve ISSUE-18 as proposed here: http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011May/0023.html and the Editors make sure that classes are named consistenly

souri: one last question: rr:table and rr:Table could be very confusing

michael: let's not waste our telecon time on this

<MacTed> I agree that names should not differ *solely* by a single character case.

<ivan> +1 to close the issue 18

souri: editors will take a look at the names and propose something in email

<alexdeleon> +1

+1

<cygri> +1

<betehess> +1

RESOLUTION: working group resolves ISSUE-18 as proposed here

souri: rr:subjectMap is a property, so that may be why we added Class at the ends of the class names

<mhausenblas> ACTION: Souri to implement ISSUE-18 resolution and make sure that all class and property names are meaningful [recorded in http://www.w3.org/2011/05/10-rdb2rdf-minutes.html#action02]

<trackbot> Created ACTION-126 - Implement ISSUE-18 resolution and make sure that all class and property names are meaningful [on Souripriya Das - due 2011-05-17].

ACTION-123

<mhausenblas> ACTION-123?

<trackbot> ACTION-123 -- Souripriya Das to implement decision re ISSUE-25 -- due 2011-05-10 -- OPEN

<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/actions/123

<mhausenblas> ACTION-124?

<trackbot> ACTION-124 -- Seema Sundara to implement decision re ISSUE-29 (bNodes identifier and URI expressions be of string types) -- due 2011-05-10 -- OPEN

<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/actions/124

souri: not done yet

seema: not done yet

michael: on to open issues

Open issues

<mhausenblas> ISSUE-32?

<trackbot> ISSUE-32 -- Remove the use of curly braces in joinCondition -- open

<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/32

<cygri> http://www.w3.org/2001/sw/rdb2rdf/r2rml/#RefObjectMapClass_joinCondition_Property

cygri: this is in the spec

<cygri> {childAlias.}deptno = {parentAlias.}deptno

<cygri> {childAlias}.deptno = {parentAlias}.deptno

<cygri> childAlias.deptno = parentAlias.deptno

cygri: these are the options

ivan: what was the original reason for {}

souri: so it is easy to replace them with the alias for the parent/child tables
... trying to avoid parsing

cygri: what about case when join covers multiple columns

souri: join condition could be a compound expression with AND, etc.

cygri: so if we remove {} then there could be a clash with a table named childAlias

michael: what is simplest solution

cygri: to not allow arbitrary expressions but to only allow simple equality checks

if there were multiple columns to join on

then there would be multiple values of the join property

<cygri> "childAlias.col1=parentAlias.col1", "childAlias.col2=parentAlias.col2"

+1 to what richard just said

ashok: questions about allowing SQL here

<cygri> another option: "col1=>col1", "col2=>col2"

Ashok: end up specifying what parts of SQL can and cannot be used, would rather not do this
... SQL is SQL, use whatever you want

eric: doesn't that break use-cases for pushing queries down

e.g. someone is unnecessarily using vendor extensions to declare part of a view

ted: vendor extensions cannot be stopped

eric: can we get useful work done if we start parsing something but it has vendor extensions?

ted: good product will do everything for $$$

ashok: i was not talking about vendor extensions, but merely restricting SQL

dmcneil: he means only allowing a subset of SQL in this property

(i think)

cygri: what we are doing with this join condition is making an explicit that a FK is to be used

to join two tables

where tables are logical tables

but this only works if the FK constraint holds

constraining the SQL here makes some sense becuase we are just doing a FK join, not a general cosntraint

<Souri> agree with Richard

michael: ashok - do you have a concrete proposal?

ashok: proposal is to allow full SQL syntax

otherwise we need to document what you can and cannot do

which is confusing

also, not sure what we are buying with this

but we can write complicated parsers

cygri: the reason this is wierd is because we have a literal with something that looks like SQL, but really we didn't want to break the entire thing down into RDF

proper way would be to model it as many triples in RDF

<Souri> if we limit to equality checks only, then conceptually, it could be a list of ordered pairs (for pure referential constrains, that is sufficient)

instead of that we just use micro-syntax borrowed from SQL here

<cygri> rr:joinChild "parentID"; rr:joinParent "ID";

maybe we should just bite the bullet and use RDF

<cygri> rr:joinChild ("parentID1", "parentID2"); rr:joinParent ("ID1", "ID2);

souri: could be a list of ordered pairs, the current spec is more flexible than this, but is it needed?

michael: stepping back a bit, on ISSUE-32, are we ready to provide a proposal to resolve it with what richard proposed?

cygri: i will volunteer to take an action to write a proposal to the list

<mhausenblas> ACTION: Richard to write up a proposal to resolve ISSUE-32 based on today's discussion [recorded in http://www.w3.org/2011/05/10-rdb2rdf-minutes.html#action03]

<trackbot> Created ACTION-127 - Write up a proposal to resolve ISSUE-32 based on today's discussion [on Richard Cyganiak - due 2011-05-17].

<mhausenblas> ISSUE-34?

<trackbot> ISSUE-34 -- R2RML terminology: addressing vendor-specific names like "owner" -- open

<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/34

souri: this is about finding a non-vendor-specific term

cygri: this requires looking into SQL spec to see what term is used there (that is one way of resolving it)

<mhausenblas> ISSUE-35?

<trackbot> ISSUE-35 -- Case sensitivity of SQL identifiers -- open

<trackbot> http://www.w3.org/2001/sw/rdb2rdf/track/issues/35

dmcneil: r2rml should treat identifiers as db does

ashok: i agree

<MacTed> which locks the R2RML you write today onto the DB engine you use today?

cygri: mysql, by default they are not case sensitive, but special quotes makes them case sensitive

souri: same in Oracle, "" makes them case sensitive

cygri: would you use "" in R2RML?

ted: the quote character changes with engine, whether they exist changes with engine, canonical case changes with engine

in most cases the engine will convert all identifiers to a canonical case until quote chars appear

it is very hard to have a simple answer: do it this way

this is why apps are written to universal APIs which translate to db specific manner

by saying R2ML must match the engine we doom the implementors

<betehess> /me is more and more worried that R2RML won't be portable but tied to the underlying DB that is used. let's imagine if HTML was defined this way

did we decide on full or core SQL?

cygri: if you don't use pure SQL then you are not doing R2RML any more (?)

<cygri> MacTed: see http://www.w3.org/2001/sw/rdb2rdf/r2rml/#sql-conformance

<cygri> this is ISSUE-22

souri: if user uses camel case, then we propagate that directly to database, up to db to interpret

+q

-q

<mhausenblas> Michael: we MUST specify what SQL we're targeting - will take an action to update the UCR doc http://www.w3.org/TR/rdb2rdf-ucr/

ted: oracle turns the identifiers to all caps unless they are quoted
... could treat it as case insensitive unless it is quoted then treat it as case sensistive

cygri: would you put the quotes in the Turtle representation of the mapping?

<Ashok> Do DB2 and SQLServer have the same rules re. identifiers?

ted: user needs to add quotes to make it case sensitive

if the engine fails then they need to change it

cygri: in R2RML there are several places where values are column names

ted: if those values are not quoted delimited then they are case insensitive

<cygri> rr:table "\"ThisIsQuotedTableName\"";

the issue also has to do with sepcial chars, not just casing

<mhausenblas> ACTION: Hausenblas to find the resolution re what SQL and SPARQL we address and make this explicit core requirements in the UCR document [recorded in http://www.w3.org/2011/05/10-rdb2rdf-minutes.html#action04]

<trackbot> Created ACTION-128 - Find the resolution re what SQL and SPARQL we address and make this explicit core requirements in the UCR document [on Michael Hausenblas - due 2011-05-17].

cygri: SQL and Turtle quoting are mixed together, but that is the price to pay
... in D2R quotes are not used, up to the implementation to figure it out, but doesn't work really well

ted's proposal is really ugly but might be right

souri: identifiers could also include special characters

that was one of the motivations for {}

column names can have a space in them

<cygri> PROPOSAL: SQL identifiers in R2RML are case insensitive by default, and become case sensitive when enclosed in the R2RML delimiter (TBD). This should be noted in the spec as something we seek feedback on.

PROPOSAL: SQL identifiers in R2RML are either case sensitive or insensitive (configurable) and become case sensitive when enclosed in an R2RML specified quote character

ashok: does this agree with the SQL standard?

cygri: I think it matches what Oracle allows

<MacTed> "double-quote" is implementation specific

would be good to double-check the spec

ashok: I can find out about DB2 and SQL-Server

ted: this should not be based on the engines, but should be based on the spec

<mhausenblas> ACTION: Ashok to check re DB2 and SQL-Server for ISSUE-35 (case sensitivity of SQL identifiers) [recorded in http://www.w3.org/2011/05/10-rdb2rdf-minutes.html#action05]

<trackbot> Created ACTION-129 - Check re DB2 and SQL-Server for ISSUE-35 (case sensitivity of SQL identifiers) [on Ashok Malhotra - due 2011-05-17].

ted: don't use db engines quote character because it is variable, there is a db call to get it, can be overriden by an app

cygri: simplest case is to pass the queries as-is on to the engine

ted: then let them get an error if it fails

cygri: but simplest implementation should work

+q

<Souri> Another option: Could we prescribe a syntax for specifying case-sensitive column names in R2RML? Then we translate the mapping based upon the input and the target SQL engine.

<mhausenblas> [meeting adjourned]

<mhausenblas> trackbot, end telecon

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/end up specifying/Ashok: end up specifying/
Succeeded: s/SQL is SQL/Ashok: SQL is SQL/
Succeeded: s/DB engine's quote character/R2RML delimiter (TBD)/
Found ScribeNick: dmcneil
Inferring Scribes: dmcneil
Default Present: alexdeleon, mhausenblas, Ivan, dmcneil, MacTed, Ashok_Malhotra, cygri, +575737aaaa, juansequeda, Souri, Seema, Alexandre, privera, EricP
Present: alexdeleon mhausenblas Ivan dmcneil MacTed Ashok_Malhotra cygri +575737aaaa juansequeda Souri Seema Alexandre privera EricP Alex D Michael David Ted Richard Ashok Juan Percy Eric
Regrets: Marcelo Soeren Boris Nuno
Agenda: http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011May/0020.html
Found Date: 10 May 2011
Guessing minutes URL: http://www.w3.org/2011/05/10-rdb2rdf-minutes.html
People with action items: ashok hausenblas richard souri

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.