RDB2RDF Working Group Teleconference -- 01 Jun 2010

<trackbot> Date: 01 June 2010

<lima> Li Ma is using skype for the meeting. IPcaller is Li Ma

<mhausenblas> scribenick: juansequeda

Admin

PROPOSAL: accept meetings from last meeting

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

RESOLUTION: Meetings from last time are accepted

FPWD of Use Case Document

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

<mhausenblas> Ahmed's http://www.w3.org/2001/sw/rdb2rdf/wiki/Ahmed%27s_UCR_Review

We are going to go through Ahmed's comments: http://www.w3.org/2001/sw/rdb2rdf/wiki/Ahmed's_UCR_Review

The first two sections of ahmed's comments (motivation and use cases) are fine.

We will continue on Section 3: Requirement Section

Ahmed: I think functional req can be done better, but this is a draft
... there is nothing in the use cases about mapping data types
... this should be part of the requirements

mhausenblas: the req of the data types are there but don

but don't show up in the use cases?

Ahmed: there are req that are not in the use cases at all, but need to be in the req (i.e. data types)
... how are we going to support vendor specific datatypes.
... this is not in the use cases, but it needs to be in the req

mhausenblas: are you proposing a new requirement?

Ahmed: if I understand microparsing, I would call it Custom Mapping to Unique Database Vendor Specific Data Types
... but I'm not sure

Ashok: I think it is a different thing.

Ahmed: I really don't know what it is

Ashok: should we add a req that supports vendor specific datatype?

Ahmed: Yes

Ashok: lets ask the group

PROPOSAL: add a core req, Vendor Specific Datatypes

orri: It is difficult because everybody has their own

orri describes different datatypes from different vendors

mhausenblas: orri, could you write text about this req?

orri: yes

Ashok: do we need this as a core requirement or should we think about allowing extensibility within the mapping language
... and then doing the vendor specific datatype supports through that
... through an extensibility mechanisim?

mhausenblas: this makes sense, but then the extensibility should be a core requirement and we could do the vendor specific datatype support through this req

<mhausenblas> PROPOSAL: R2RML MUST provide an extensibility mechanisim to allow for Database Vendor Specific Data Types mapping

<Souri> +1

<alex> +1

<lima> +1

RESOLUTION: add new core requirement data vendor specific data types

R2RML MUST provide an extensibility mechanisim to allow for Database Vendor Specific Data Types mapping

Ahmed: I have my reservation with the automatic mapping
... you map it to RDF, and what are you going to do with this?

orri: some use cases will have an integration aspect
... this can be used to create a template

Ahmed: it is more of a means than an end

<Zakim> ericP, you wanted to mention d2r use

EricP: the default mapping in D2R gets a lot of use.
... get the data in a form where people can query with sparql
... and then it can be mapped

<Souri> +1 to EricP

EricP: I can have my protein database, and then somebody else can creates mapping to specifc ontologies

Ahmed: about SQLGEN, I don't think SPARQL to SQL is part of the charter

EricP: the world is expecting us to enable them to create RDF views of their data and then they can do queries over

Ahmed: This is something that needs to be done, but it is expected to be done by somebody else, and maybe not in this group

<hhalpin> as we've noted before, the charter allows both ETL and possible SPARQL to SQL

<hhalpin> via this requirement "The mapping language MUST define the set of relational algebra to be supported in the first release. This set to be supported SHOULD be as complete as possible and be defined as soon as possible after the WG official launch."

<Souri> +1 to Ahmed (I do not think it is part of our charter: we can allude to it, but not solve it)

mhausenblas: we can't cover everything, but we want to make sure that it can be done
... I'm fine with the current phrasing
... but what is written is within the charter

<Ahmed> q

hhalpin: looking from a procedural manner, giving the time we have left... if you look at the req:
... "The mapping language MUST define the set of relational algebra to be supported in the first release. This set to be supported SHOULD be as complete as possible and be defined as soon as possible after the WG official launch."
... the right thing to do is to allude that it is possible but do no make it a MUST req. instead a MAY or SHOULD req

<Souri> +1 to hhalpin

+1 to hhalpin

Ahmed: can somebody give me an example of a potential piece of data that can help sparql to sql

ericP: it sounds that the dispute is if the language we produce should allow people to run sparql to sql, instead of using it to create a materialized view
... should we stick to the latter?

Ahmed: I would say that if we could communicate with the team that is going to do the sparql to sql mapping, and leave it to that

ericP: the majority of my users find it a non-starter if we don't have sparql to sql
... they will not be motivated to produce materialized rdf views
... the amount of data that you can put in a triple store is tiny vs what you can put in a relational store

Ashok: do we have to tell them how the sparql gets translated to sql ?

ericP: I don't believe the wording says that

<Souri> maybe we should say an implementation should be able to support a SPARQL query on the mapped data (whether materialized or not), but how we do it and how the translated SQL looks, we don't care

+1 to Souri

hhalpin: people want to know what they can expect from the mapping

<hhalpin> I'm happy with that formulation....

ericP: what we are going to deliver to the world will allow people to make these transformations

<hhalpin> but not sure if that requires a text change.

<Souri> +1 to Orri and Harry(?) about identifying some restrictions on which constructs of SPARQL1.1 we support

We leave the section 3.1.4 as it stands

<hhalpin> Yes, agreed Souri, but I don't htink we can make those restrictions quite yet.

Ahmed: in SQL Data Types Supported, why did we stop at SQL 92?

<mhausenblas> currently: section 3.1.6 read:

<mhausenblas> Relational data types MUST be treated consistently with RDF datatypes per SQL-XSD mapping ISO IWD 9075-14:2011(E) Subclause 9.5, "Mapping SQL data types to XML Schema data types"

ericP: I worked on that section with Jim Melton
... if we find that this is insufficient, then we will go to the ISO group

Ahmed: if that is the case, then we shouldn't use MUST

ericP: I'm more comfortable with the must, because we don't want to split the standards

<hhalpin> thinks we should be careful with MUST :)

ericP: I'm expecting a review from the ISO group

<Souri> +1 to ericP's points

ericP: I propose no change

<hhalpin> I'm OK

Ashok: I agree with ericP

Ahmed: what is microparsing:?

mhausenblas: that is now table parsing
... I tried to explain it in the sense that some tables have cells where there are structured values

ericP: I put it in the doc, but I was copying it from the wiki

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

Ashok: the question is if this is a MUST req, or could we have it as a "nice to have"

ericP: I put it there by pasting it from the wiki. I didn't write this

<ericP> ┌┤Patient├───┬───────────┐

<ericP> │ ID │ name │ bpressure │

<ericP> │ 11 │ Alice │ "120/70" │

<ericP> └────┴───────┴───────────┘

<mhausenblas> PROPOSAL: remove section 3.1.9 TABLEPARSING

Ahmed: I agree with removal.

<ericP> +1

<alex> +1

RESOLUTION: remove section 3.1.9 TABLEPARSING

Ahmed: what does “creation of multiple named graphs within one mapping definition?" mean

<mhausenblas> section 3.2.1

ericP: I have a table of employees and a table of tasks
... I get to create a mapping that says
... two named graphs
... HR and WorkFlow

<hhalpin> Maybe we need to explain what "named graphs" are in the use-case doc for people from SQL community.

<mhausenblas> +1 hhalpin :)

ericP: I put some of the tuples in HR and others in WorkFlow

<Souri> this was first proposed by richard cyganiak and our example (in the wiki) illustrates this

+1 hhalpin

<mhausenblas> did you just volunteer to draft that, hhalpin ?

<hhalpin> Hmmm...yes, I can do that.

<Souri> +1 add to glossary

<mhausenblas> PROPOSAL: add named graphs to the glossary

<hhalpin> I can even do that now, would say

Ahmed: it seems like this like different views

juansequeda: lets add named graph to the glossary

ericP: ... it is like a view

PROPOSAL: add named graph to the glossary

RESOLUTION: add "named graph" to the glossary

Ahmed: what does licensing mean in this context

mhausenblas: when you publish linked data, you usually publish the type of license it is under
... there are different licenses that you can add to data sets

<hhalpin> "Named Graph: A graph that is given a URI. See SPARQL and "Jeremy J. Carroll, Christian Bizer, Patrick J. Hayes, Patrick Stickler: Named graphs, provenance and trust. WWW 2005: 613-622" for details.

<hhalpin> Will e-mail that to list.

<mhausenblas> tx hhalpin

<mhausenblas> for example using http://www.opendatacommons.org/licenses/pddl/

talking about licenses...

<Souri> doc probably should include ericP's explanation in brief to avoid confusion in reader's mind

Ahmed: with in the context of databases, it is a bit confusing.
... make it clear that this is more for Linked Data

<Souri> +1 to michael (add a short example)

mhausenblas: I will add an example to this section

+1 to mhausenblas

<mhausenblas> ACTION: mhausenb to add PDDL example to sec. 3.2.3 [recorded in http://www.w3.org/2010/06/01-rdb2rdf-minutes.html#action01]

<trackbot> Created ACTION-60 - Add PDDL example to sec. 3.2.3 [on Michael Hausenblas - due 2010-06-08].

<Souri> copyright?

hhalpin: not to make a big issue on the license

<hhalpin> but it is important.

<hhalpin> lets keep it.

<hhalpin> Thank you Ahmed!!

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

<Souri> http://www.w3.org/2001/sw/rdb2rdf/wiki/Lists_of_generic_names_for_use_in_examples

use generic names in use case

<mhausenblas> PROPOSAL: Replace all WG names in examples with generic names, esp. in section 3.1.10

Souri: my proposal is to use generic names in the use cas

ericP: just use the Alice, Bob

<hhalpin> Fine with me.

<ericP> +1

<Souri> +1

RESOLUTION: replace all WG member names in example with generic names, esp section 3.1.10

<mhausenblas> PROPOSAL: WG decides to publish the UCR document as FPWD

<ericP> +1

<hhalpin> +1

<alex> +1

<Souri> +1

<hhalpin> (should we take formal consensus?)

<nunolopes> +1

<lima> +1

<Seema> +1

<hhalpin> (as in do a go around verbally on the phone?)

<LeeF> Yes, please, let's publish :)

<mhausenblas> +1

<LeeF> what, "Yes, please, let's publish" isn't clear enough? :p

<hhalpin> We just go around the list and everything voices "yes", "opposed", or "stand aside"

+1 from Boris

+1 from Ashok

+1 from Orri

<mhausenblas> http://www.w3.org/TR/rdb2rdf-ucr

<Seema> finally!

<LeeF> Seema++

<ericP> seriously

<mhausenblas> Michael: thank you everybody for your input and comments

<Souri> that will be a hard working draft

<mhausenblas> [meeting adjourned]

<mhausenblas> I note that we need the attendees list in the minutes

<mhausenblas> so, once you're done folks, juansequeda can you please do:

<mhausenblas> and then "RRSAgent, draft minutes"

<mhausenblas> ok, juansequeda?

<mhausenblas> and please don't forget to send out the meeting minutes for review to the WG, juansequeda

member: RRSAgent, draft minutes

<mhausenblas> ping hhalpin

<mhausenblas> just a quick question

<mhausenblas> should I now replace <w3c-doctype>Editors' Draft 26 May 2010</w3c-doctype> with

<mhausenblas> <w3c-doctype>First Public Working Draft 1 June 2010</w3c-doctype>

<mhausenblas> in the doc?

<mhausenblas> hhalpin? ericP?

<mhausenblas> heeeeeeeeeeeeelp :D

<hhalpin> michael

<hhalpin> the main issue is the date.

<hhalpin> should be the date of publication.

<hhalpin> but otherwise yes

<hhalpin> and we have to make sure it goes through pubrules.

<hhalpin> hold on...e-mailing Ian Jacobs (W3C Communications) and cc'ing you.

<mhausenblas> ok and ok and ok

<mhausenblas> thanks

<hhalpin> just not sure of date.

<mhausenblas> right

<mhausenblas> I can change that anytime

<mhausenblas> only external dependency is Orri's input which I hope I get tomorrow latest

<mhausenblas> ideally today ;0

<hhalpin> cool

<hhalpin> just hold on

<mhausenblas> ok

- DRAFT -

RDB2RDF Working Group Teleconference

01 Jun 2010

Attendees

Contents

Admin

FPWD of Use Case Document

use generic names in use case

Summary of Action Items

Scribe.perl diagnostic output