See also: IRC log
<trackbot> Date: 02 February 2010
<scribe> Scribenick: mhausenblas
<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
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:[End of scribe.perl diagnostic output]