<trackbot> Date: 02 February 2010

<scribe> Scribenick: mhausenblas

Admin

<BenSzekely> +1.617.306.aaaa is me

<angela_UNITN> aacc is me

Ahmed?

<BenSzekely> *4

PROPOSAL: accept minutes of previous telecon http://www.w3.org/2010/01/26-RDB2RDF-minutes.html

<ericP> +1

<soeren> +1

RESOLUTION: accept minutes of previous telecon http://www.w3.org/2010/01/26-RDB2RDF-minutes.html

<juansequeda> http://www.w3.org/2001/sw/rdb2rdf/wiki/GeneratedSQL

<juansequeda> http://www.w3.org/2001/sw/rdb2rdf/wiki/PotentialSQLIssues

<ericP> http://esw.w3.org/topic/HCLSIG/RDB2RDF_Use_Cases

work planning

ericP: how do we communicate what a mapping does
... here is the input data in relational form and here is the RDF
... so we want to pick a fairly neutral SQL and as an output a Turtle graph
... no NG for now

Ahmed: why not use RDF/XML for the output?

ericP: maybe Turtle is easier
... for manual editing/reviewing
... put the tabular, SQL form into the Wiki

soeren: for what kind of data you mean SQL? for the TC, etc?

<Zakim> mhausenblas, you wanted to ask about the focus

<ericP> INSERT INTO People (id, name) VALUES (18, "Bob"), (23, "Sue")

ericP: I'm trying to set up a framework to communicate between our TF and HCLS

soeren: should be called relational-annotation approach

Michael: I see two fundamental approaches - SQL-based mapping and dedicated-language-based mapping

cygri: I'd argue that the relational-annotation approach doesn't work for complex cases without using SQL views

soeren: a more direct approach like ericP's might perform better
... without domain-mappings

cygri: relational-annotation approach will require schema modification IMO
... if one uses relational-annotation the without schema modification, the efficiency is very bad at least on MySQL
... this leads to a big problem
... we hence need to talk about performance as well

<ericP> cygri's was talking about recent contributions to http://www.w3.org/2001/sw/rdb2rdf/wiki/PotentialSQLIssues (i believe)

soeren: performance will drop once you want a domain mapping

juansequeda: we do need two groups
... question is where the optimisation is done
... in Ultrawrap we change the scheme and let the engine do the rest

<ericP> i'm not convinced that the "schema-less" queries need to be pre-optimized any more than if they do it on the SQL side

<soeren> -q

Seema: so we have two groups? one modify schema and other non-modify schema?

<ericP> +1 to Seema's characterization

<ericP> at least, that's how i understand it

cygri: seems that people think along different lines
... schema-modify vs. non, optimising in the mapping vs. not, etc
... personally I think it doesn't matter. we will end up in two groups

<ericP> i think that the distinction based on the language of the rule body is the least controversial

cygri: we should not focus on the question of schema-modify, matter of performance
... rather focus on where the optimisation occurs

juansequeda: R2RML is a mapping language so should be independent where the optimisation is done

cygri: if done with SQL, one would naturally do the optimisation in the RDBMS
... if done outside, better have something which is easy to parse

Ashok: cygri, why optimisation focus?
... no need to duplicate the work done in the past 30y

cygri: in case of MySQl, for instance this is a problem

Ahmed: we come from the use cases
... there are cases where it is not possible to change the schema
... any mapping language we come up with needs to support all use cases

Ashok: my question is simply - why are we speaking about changing the schema?

Ahmed: because of the views

Ashok: so you're talking about creating views. IMO this is not changing the schema

Ahmed: well, maybe read-only, but still a change
... we have such scenarios in-house

Ashok: but the views don't need to be stored, just executed, right?

Ahmed: correct
... but some engines, such as MySQL have issues with it

queue

cygri: agree, that was a nice summary
... re issues, see http://www.w3.org/2001/sw/rdb2rdf/wiki/PotentialSQLIssues
... has examples in there where we have problems

Ahmed: if MySQL is limited re this, we might need another approach

juansequeda: SQLServer has no problem with it

cygri: at least for D2RQ it is true that MySQL is very often used
... so needs to work with it reasonable well
... as long as I can rewrite the query myself to deal with the specific weaknesses of the target
... I guess it's doable

<ericP> cygri, wouldn't it be easier in the long run to fix the database's optimizer? (half joking)

cygri: but shouldn't show up in the mapping lanuage
... in D2RQ the mapping is broken down onto class/prop level

<juansequeda> ericP, wetold our students to implement merge join for mysql

<ericP> cool, nice to see open source improvements

<juansequeda> oops, i meant coma

Ahmed: gotta go soon
... continue next week

[adjourned]

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/controversion/controversial/
Succeeded: s/ericP: we /ericP, we/
Found ScribeNick: mhausenblas
Inferring Scribes: mhausenblas
Default Present: hhalpin, +1.617.306.aaaa, mhausenblas, MacTed, Ericp, Ashok_Malhotra, +1.512.471.aabb, juansequeda, cygri, +039046188aacc, +49.322.22.aadd
Present: hhalpin +1.617.306.aaaa mhausenblas MacTed Ericp Ashok_Malhotra +1.512.471.aabb juansequeda cygri +039046188aacc +49.322.22.aadd
Regrets: Marcelo Li Ma Harry
Agenda: http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2010Feb/0000.html
Found Date: 02 Feb 2010
Guessing minutes URL: http://www.w3.org/2010/02/02-RDB2RDF-minutes.html
People with action items: