<trackbot> Date: 11 May 2010

<mhausenblas> scribenick: cygri

1. Admin

PROPOSAL: Accept the minutes of the 4 May 2010 telecon,

http://www.w3.org/2010/05/04-rdb2rdf-minutes.html

<hhalpin> +1

RESOLUTION: Accept the minutes of the 4 May 2010 telecon http://www.w3.org/2010/05/04-rdb2rdf-minutes.html

2. Introduction of new members

<hhalpin> I can send them a quick e-mail with telecon instructions.

intro email from Boris and Alexander: http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2010May/0024.html

3. Use Case Document

<hhalpin> perhaps they had some issues calling in.

<mhausenblas>

draft is here: http://www.w3.org/2001/sw/rdb2rdf/use-cases/

<hhalpin> well, we need to make sure the working draft is well-formed english :)

<hhalpin> but all of my comments are minor, and do not cause substantial changes to text.

<hhalpin> Usually "authors" are people who contributed substantial amounts of text

<hhalpin> "Contributors" are people who sent in, say, comments.

<hhalpin> That is more or less W3C process.

<hhalpin> to my knowledge.

<hhalpin> +1 marcelo

Marcelo: authors should be who contributed to writing of use cases, not everyone

<seema> +1 to marcelo's suggestion

mhausenblas: all members would typically listed in the acknowledgements

<ericP> PROPOSED to list WG members in acknowldgements

<ericP> PROPOSED to list WG members in acknowldgements and keep author list as it

<Marcelo> +1

<juansequeda> +1

+1

<hhalpin> _1

<ericP> APPROVED

<hhalpin> +1

ericP: I addressed Ahmed's comment
... Juan didn't want to have SQL query in use case

Juan: it's enough to *say* we translate to SQL, we don't need to *show* it

thanks mhausenblas

RESOLUTION: list WG members in acknowldgements and keep author list as it

Juan: the specific SQL depends on implementer so let's not show one specific

ericP: but we should show that we can do an effective job

<hhalpin> ericP added this "This query is not a normative representation of the earlier SPARQL query; it is included here only to illustrate the ability of R2RML tools to produce efficient SQL queries."

mhausenblas: let's focus on the document, we want to get first draft out today

<hhalpin> I propose that

<hhalpin> s "This query is not a normative representation of the earlier SPARQL query; it is included here only to illustrate that R2ML could produce efficient SQL queries."

<hhalpin> Well, my proposal is just as easy to read in IRC as anywhere else.

<ericP> current text says "This query is not a normative representation of the earlier SPARQL query; it is included here only to illustrate the ability of R2RML tools to produce efficient SQL queries.

<ericP> "

<hhalpin> Thus, we do not say that we *have* to produce efficient SQL, but implementations *could*.

Ashok: this sentence is too weak, it doesn't say anything

<hhalpin> Ashok - that sentence is from EricP.

<hhalpin> I changed ONE word.

mhausenblas: let's take it as editorial note for now

<hhalpin> i.e. said it "could" produce SQL queries.

PROPOSAL: ed note: "This query is not a normative representation of the earlier SPARQL query; it is included here only to illustrate that R2ML could produce efficient SQL queries."

<hhalpin> Let's do a go around on deleting or keeping that SQL query in then.

seema: let's not put a sql query

(ericP and MacTed talk about wether efficiency is relevant in the context of the use case)

PROPOSAL: separate section, independent from the use cases, that says "this sparql might be translated to this efficient sql"

<hhalpin> why not just keep that text in the use-case?

<hhalpin> we have enough sections as is.

<hhalpin> its actually better to have it in use-cases rather than requirements.

Juan: why not stick it in section on requirement "sql generation"?

hhalpin: in requirements, it sounds like we *require* efficient sql to be produced

Juan: but we have the "sql generation" section already

<hhalpin> I'm saying it causes minimum damage in the "use case" docuemnt

MacTed: everyone wants efficient sql obviously. the important thing is that every sparql query is rendered as executable sql. efficiency is not important.

ericP: my use case has to do with querying massive numbers of records. efficiency is key to that use case. i want to keep it there

<hhalpin> So maybe add "This query is not a normative representation of the earlier SPARQL query; it is included here only to illustrate the ability of R2RML tools to produce efficient SQL queries" -> "This query is not a normative representation of the earlier SPARQL query; it is included here only to illustrate the ability of R2RML tools to possibly produce efficient SQL queries, although our mapping file will not mandate any particular transformation of SPARQL to

<hhalpin> SQL."

<hhalpin> just to be clear.

<hhalpin> +1 a vote

<mhausenblas> I agree, but we need a question ... :)

<mhausenblas> ideally on IRC

<juansequeda> Who wants to put SQL in the use case document?

PROPOSAL: leave the SQL there as an ed note, with
... leave the SQL there as an ed note, with hhalpin's proposed rewording

+1

<ericP> +1

<hhalpin> +1

<LeeF> The requirement really sounds like to avoid a design that precludes generating efficient SQL queries

<Marcelo> +1

<LeeF> +1 to having a SQL query example in UC&R

<angela_Unitn> -1 have sql query

<hhalpin> (Note that the rewording mentions a SQL query in a use-case, with the following text: This query is not a normative representation of the earlier SPARQL query; it is included here only to illustrate the ability of R2RML tools to possibly produce efficient SQL queries, although our mapping file will not mandate any particular transformation of SPARQL to SQL.

<Ashok> -!

<hhalpin> ) I was hoping that text addresses Juan's concern.

<seema> -1

<whalb> +1

<seema> i would rather just have the wording..not the SQL

<MacTed> -1

<juansequeda> -1

<juansequeda> dan: -1

<hhalpin> This is rather close...

<hhalpin> perhaps we should try a "Can we live with it being removed" vote?

<MacTed> english saying "the R2RML allows for translation of arbitrary SPARQL to executable SQL. efficiency is left as an excercise for the implementor." ;-)

PROPOSAL: remove sql query from the document

<hhalpin> PROPOSAL: Remove SQL query and associated text from document.

<LeeF> Abstain.

<hhalpin> We could do a straw poll again...

<hhalpin> well the associated text doesn't make much sense without the SQL query.

<ericP> abstain

<hhalpin> We could try to add some suitable text there if we can think of some.

<hhalpin> ericP - can you think of some text that can be added in that satisfies you?

mhausenblas: any objections?

RESOLUTION: Remove SQL query and associated text from document.

dan: i'd keep the general notion of the section's first paragraph, but without the query

ericP: sören suggested to move UC5 and UC6 to requirements
... i moved them to the requirements, MANYTOMANY and VALUETYPE

<LeeF> I'm ok with it.

<hhalpin> like " The RDF graphs defined by a mapping over a relational database need not be materialised. Indeed, queries or inference may be expressed in terms of a notional representation of relational data, but executed over the original relational store. Executing a SQL query over any data in the relational tables should give results identical to a SPARQL query over the RDF graph mapped from that relational data. While our specification will not produce a normat

<hhalpin> ive SQL representation of arbitrary SPARQL query; although RDB2RDF tools could possibly produce efficient SQL queries from SPARQL queries without materialization."

ericP: anyone has issues with this?

<hhalpin> There's some text based on EricP's minus any reference to an actual SQL query.

<ericP> PROPOSE 4.1.8 MANYTOMANY and 4.1.9 VALUETYPE address Soren's and Juan's comments around UC5 and 6

PROPOSAL: 4.1.8 MANYTOMANY and 4.1.9 VALUETYPE address Soren's and Juan's comments around UC5 and 6

<MacTed> +1

+1

<juansequeda> +1

<ericP> APPROVED

RESOLUTION: 4.1.8 MANYTOMANY and 4.1.9 VALUETYPE address Soren's and Juan's comments around UC5 and 6

Juan: UC3 is the only one that has all these sections

ericP: are you ok with publishihng UC3 as is, and clean it up later?

<angela_Unitn> for me you can clean them up

<hhalpin> and the rest of the formatting around UC3.

<hhalpin> that separates it from other use-cases.

<angela_Unitn> +1

<hhalpin> propose making UC3 like the rest of the use-cases!

<hhalpin> i.e. remove special formatting.

<ericP> PROPOSED: public UC3 as in 1.34

<angela_Unitn> +1

<ericP> APPROVED

<hhalpin> +1

PROPOSAL: publish UC3 as in 1.34

RESOLUTION: publish UC3 as in 1.34

(ericP, Juan, MacTed discuss Juan's image)

http://userweb.cs.utexas.edu/~jsequeda/rdb2rdf/

mhausenblas: can you sort this out via email after the call?

<MacTed> +1

ericP: PROPOSAL: keep the Approaches section as is, except for tweaking the image

PROPOSAL: keep the Approaches section as is, except for tweaking the image

<juansequeda> +1

RESOLUTION: keep the Approaches section as is, except for tweaking the image

<hhalpin> It does seem a bit repetivie with Section 4, so I'll +1 once I get to e-mail in some minor textual changes.

hi alexander

we're in the call, started 45min ago ...

<MacTed> 4.1.1 Direct Mapping -- RDB Schema to Local RDF Ontology

<MacTed> 4.1.2 Transformative Mapping -- RDB Schema to Domain RDF Ontology/ies

PROPOSAL: change titles of 4.1.1and 4.1.2 as per MacTed above

<alexander> Hello, sorry, we though that the conference was at 7PM our time

<MacTed> 4.1.2 *could* be Tranformative Mapping -- Local RDF Ontology to Domain RDF Ontology/ies

<mhausenblas> alexander, did you receive the invitation mail?

<mhausenblas> see http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2010May/0034.html alexander

<mhausenblas> there is a link in this mail, see http://www.timeanddate.com/worldclock/fixedtime.html?month=05&day=11&year=20

<mhausenblas> should be unambiguous ;)

alexander, this happens to everyone the first time ;-)

<alexander> Thank you, yes we received but for some reason we got confused with the times... sorry

<mhausenblas> no worries, yeah, alexander - can you dail in now?

<alexander> yes we are trying to to do that now

<mhausenblas> ah, ok, alexander

<hhalpin> -1 proforma schema

<hhalpin> we just need to "choose" terms.

<hhalpin> We should choose terms preferred by database community, NOT RDF community.

MacTed: let's stick to local ontology and domain ontology
... if we simply state what they mean, it should be fine

<hhalpin> +1 MacTed

<hhalpin> I mean, most database administrators will likely have little idea what OWL is.

<seema> +1 Tes

<hhalpin> As long as we clearly define our terms and use the terms known by people in the database community.

ericP: can we say "... convert to an RDF graph conforming to an ontology"?

hhalpin: database people don't use terms like "graph conforming to an ontology"

ericP: but do rdf people understand "local ontolgy" etc?

<hhalpin> Could someone from a database background speak-up?

<hhalpin> I'm happy with EricP's rewording to make it precise.

<LeeF> "instance data"

<hhalpin> +1 with Michael's terms, and add clarifying text re local and domain ontology

PROPOSAL: name 4.1.1 Direct Mapping, 4.1.2 Transformative Mapping

<ericP> +1

+1

<ericP> RESOLVED

RESOLUTION: name 4.1.1 Direct Mapping, 4.1.2 Transformative Mapping

MacTed: identifiers are for machine use, labels are for human use
... create a glossary?

PROPOSAL: add a glossary/terminology section as new Section 1.4, to clarify issues around identifier/label etc

<MacTed> identifier, label, local ontology, domain ontology ...

<hhalpin> My edits are all grammatical, minor edits to formatting.

<Marcelo> +1 for adding a glossary

RESOLUTION: add a glossary/terminology section as new Section 1.4, to clarify issues around identifier/label etc

<hhalpin> Seems like glossary could also clarify the mapping between database terminology of local/domain ontology and SemWeb use of word ontology.

<hhalpin> +1 for adding glossary

MacTed: connection information (jdbc etc) is implementation detail

ericP: jdbc style for expressing that information can be used without jdbc drivers
... there can be user benefit in combining connection and map

MacTed: connection information is fine, but it should not show jdbc as example

mhausenblas: doc does not mention jdbc

MacTed: fine

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

ericP: we can live without more references for first publication

<ericP> PROPOSED: to dispatch Li Ma's comments http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2010May/0038 after first publication

<ericP> +1

<ericP> APPROVED

+1

<mhausenblas> PROPOSAL: WG decides to publish the UCR document as FPWD with the corrections as resolved as today

<ericP> +1

<angela_Unitn> +1

<juansequeda> +1

+1

<whalb> +1

<hhalpin> +1 (more minor editorial/grammatical changes to be sent in today)

<seema> +1

<Marcelo> +1

RESOLUTION: WG decides to publish the UCR document as FPWD with the corrections as resolved as today

<hhalpin> hhalpin

<mhausenblas> ACTION: hhalpin to take fixed UCR document and publish as FPWD + TR URI [recorded in http://www.w3.org/2010/05/11-rdb2rdf-minutes.html#action01]

<trackbot> Created ACTION-54 - Take fixed UCR document and publish as FPWD + TR URI [on Harry Halpin - due 2010-05-18].

ericP: i'll just comment out the SQL stuff
... are we happy to just publish and link to juan's images?
... don't want hosting of the images to be in the critical path towards publication

<hhalpin> +1 fixing image, but NOT have it linked outside of w3 space.,

ericP: is rest of WG happy to accept whatever MacTed and juan come up with for the images?

(no objections)

<mhausenblas> [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/Le Ma/Li Ma/
Found ScribeNick: cygri
Inferring Scribes: cygri
Default Present: +043316876aaaa, +1.781.273.aabb, +1.562.249.aacc, whalb, +1.603.897.aadd, MacTed, +1.512.471.aaee, hhalpin, Ashok_Malhotra, seema
Present: +043316876aaaa +1.781.273.aabb +1.562.249.aacc whalb +1.603.897.aadd MacTed +1.512.471.aaee hhalpin Ashok_Malhotra seema
Found Date: 11 May 2010
Guessing minutes URL: http://www.w3.org/2010/05/11-rdb2rdf-minutes.html
People with action items: hhalpin