RDB2RDF Working Group Teleconference -- 16 Aug 2011

<trackbot> Date: 16 August 2011

<scribe> scribenick: mhausenblas

<dmcneil> does anyone else hear the echo?

<Seema> y

Admin

PROPOSAL: Accept the minutes of last meeting http://www.w3.org/2011/08/09-rdb2rdf-minutes.html

<boris> +1

<Marcelo> +1

RESOLUTION: Accept the minutes of last meeting http://www.w3.org/2011/08/09-rdb2rdf-minutes.html

Current actions and issue review

ACTION-140?

<trackbot> ACTION-140 -- Boris Villazón-Terrazas to produce an RDF Schema representation of the R2RML vocabulary terms. -- due 2011-08-16 -- OPEN

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

<boris> http://mccarthy.dia.fi.upm.es/rdb2rdf/r2rmlvocab.owl

ACTION-147?

<trackbot> ACTION-147 -- Richard Cyganiak to implement ISSUE-29 resolution by stating that conversion to string is done implicitly in any context where a string value is required, and is done according to the rules for SQL's CAST expression. Columns whose type cannot be CAST to string MUST NOT be used in a context that requires a string; and mark the issue as pending review -- due 2011-08-16 -- OPEN

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

<ericP> no clue

ACTION-152?

<trackbot> ACTION-152 -- Juan Sequeda to figure out and solution with Souri to address ISSUE-64 -- due 2011-08-16 -- OPEN

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

ACTION-153?

<trackbot> ACTION-153 -- Marcelo Arenas to draft a solution for ISSUE-65 and send out to WG -- due 2011-08-16 -- OPEN

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

Michael: there was a proposal to close both ISSUES-64 and ISSUE-65?

Juan: Let's close the two actions and discuss the issues later

close ACTION-152

<trackbot> ACTION-152 Figure out and solution with Souri to address ISSUE-64 closed

close ACTION-153

<trackbot> ACTION-153 Draft a solution for ISSUE-65 and send out to WG closed

ISSUE-64 and ISSUE-65

ISSUE-64?

<trackbot> ISSUE-64 -- Predicate IRI design for foreign key does not handle common cases where same column sequence may be used for multiple foreign key constraints -- open

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

<dmcneil> michael - maybe you could try muting your phone when others are speaking?

ISSUE-65?

<trackbot> ISSUE-65 -- For uniformity and performance, "literal" triples must be always generated for each child table column in a foreign key -- open

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

<dmcneil> no that is not better

<MacTed> try muting through Zakim?

<ericP> PROPOSAL: to close ISSUE-64 noting that the current DM definition generates triples for all foreign keys even if they are on the same columns

<dmcneil> the echo stopped

(Eric explains the background on the proposal)

<Souri> example: Family <f, n, spouse>, Employee <f, n, salary>, Soccer <f, n, goals>

Eric: cost re ISSUE-64 are to high and use case is not clear

Juan: agreed

<Souri> two different properties need to have two different ranges

Souri: fine with me, I thought it's needed for completness
... see my example above

<Zakim> cygri, you wanted to say that that ISSUE-64 is a very minor issue because it's such a small corner case

<Marcelo> +q

Richard: would also be possible to say that the 'ugly' but complete URI only generated in case of clash

Marcelo: also related with ISSUE-65
... problem there is in case of FK with one attribute
... to avoid this we need a different URI

<Souri> +1 to Marcelo regarding issue with literal property and constraint property

Juan: should we note the incompleteness in the spec?

<ericP> +1 to cygri's propsal

Souri: re ISSUE-65 ... as Marcelo says

<cygri> PROPOSAL: close ISSUE-64 by adding a note to the spec stating, "if multiple FKs are defined on the same sequence of columns, then the same property IRI will be used"

<Souri> -1 to ISSUE-64 proposal because it causes confusion for ISSUE-65

Michael: Noted, Souri, but this doesn't help me ...

scribe confused, doesn't understand what Ted is talking about

<Zakim> ericP, you wanted to say that the current spec only generates a reference triple for what would be the ambiguous cases

Michael: I think Richard has a point, let's try 65 first

<juansequeda> +1 to address 65 first

ISSUE-65

<Souri> the whole idea of having different approach for single-col fkey and multi-col fkey seems confusing

Richard: Agree with Souri re current design is a bit confusing

ISSUE-65?

<trackbot> ISSUE-65 -- For uniformity and performance, "literal" triples must be always generated for each child table column in a foreign key -- open

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

Richard: if we had a way to distinguish FK from literal this would be easier

<Souri> +1 to Richard's non-concrete proposal: put a prefix say "fkey"

Souri: Agree with Richard
... as long as we can distinguish the two cases

Juan: So, what you want is XXX

<Souri> fkey/f,n

<juansequeda> Juan: So, what you want to know through the IRI if it represents a literal or foreign key

<juansequeda> Souri: yes

<Souri> absolutely agree with Richard: we need to distinguish between literal (data) property and fkey (object) property

<ericP> i think anything we come up with would look like:

<ericP> <People/ID=7> <People#LID> 7 .

<ericP> <People/ID=7> <People#Lfname> "Bob" .

<ericP> <People/ID=7> <People#Laddr> 18 .

<ericP> <People/ID=7> <People#Raddr> <Addresses/ID=18> .

<ericP> note the L or R

<ericP> i also think these will be worse warts than is the unary foreign key exception

<juansequeda> ericP: that works... but it's kind of a hack

Michael: DM Editors propose solution for ISSUE-64 and ISSUE-65 after the call today and send to list (Richard to comment on)

ISSUE-48

ISSUE-48?

<trackbot> ISSUE-48 -- Mapping SQL datatypes to RDF -- open

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

<ericP> juansequeda, agreed. but i think there's no avoiding it if we want to keep the namespaces (for e.g. the People properties) sane

Michael: Got everything you need?

Richard: yes

<juansequeda> <People/ID=7> <People#fname> "Bob" .

<juansequeda> <People/ID=7> <People#addr> <Addresses/ID=18> .

<juansequeda> <People#fname> rdf:type owl:DatatypeProperty

<juansequeda> <People#addr> rdf:type owl:ObjectProperty

<juansequeda> where anything that is an owl:DatatypeProperty is for literals and anything that is owl:ObjectProperty is for foreign keys

<Souri> eric what would be the syntax for 2-col key: <SOCCER#Rf,n> ?

Richard: will send out proposal in the next couple of days

ISSUE-57

ISSUE-57?

<trackbot> ISSUE-57 -- R2RML doesn't allow R2RML documents in RDF/XML syntax -- open

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

Souri: We will not object now

Richard: two ways how to look at it
... either not discuss it now and have a second LC or resolve it now
... Would be good to resolve it before LC
... what I don't understand is why the objection is here in the first place

Souri: It's more about document structure

scribe unsure if this is capture correctly

Souri: better would be two split this
... into vocab and serialisation

<cygri> mhausenblas, please mute yourself and come over here

<cygri> your phone is broken

Souri: people should have an option

<cygri> mhausenblas, your phone is broken

<cygri> come over here

Michael: we can do this but then 1 Sep is not an option

Richard: I understand this (re modularity) but we have two competing design goals
... interop vs. flexibility

Souri: it's just an option

Michael: For the record - I'd rather step down as a co-chair than loosing the most important aspect of a standard: interoperability

Richard: not very compelling to me

Juan: IIUC then you can reuse existing ontology editors

Souri: vocab is the important part

Juan: so R2RML is just a vocab?
... quite late in the game, this issue, isn't it?

Souri: it's not too late, it's simple to write

Ashok: are people open for a compromise - replace the MUST with a SHOULD?

Richard: ... It depends ... the spec defines several conformance criteria
... processor, doc, graph
... I'm happy to say nothing at all for the processor
... but doc MUST be Turtle

Michael: I agree

<ericP> right now, an R2RML doesn't need an XML processor

<Souri> Document conforming to R2RML vocab vs. Document conforming to R2RML vocab using Turtle syntax

<ericP> +1 to cygry's terminology separation

<MacTed> MUST accept R2RML graph, SHOULD accept Turtle, MAY accept other serializations... ?

<Souri> Two-level Recommendations: 1) Vocab only 2) Vocab + Turtle

<ericP> Souri, don't we alrady have that?

<ericP> (with Richard's wording?)

<cygri> ericP, not quite. a processor currently MUST support turtle

Michael: I want to ensure interoperability

<ericP> ahh, R2RML is an a mapping graph expressed in Turtle?

<cygri> ericP, what do you mean by "R2RML"?

Richard: Seems there is no consensus ATM
... will likely not be resolved in the next two weeks
... that means more feedback from WG-external

<MacTed> RFC-standard "SHOULD accept Turtle" means "do it unless there's a damn good reason not to" ... which it seems to me assures interop

Michael: Then we need to go for a 2nd LC

<Souri> I still do not see anything wrong with Two-level Recommedations: 1) Vocab only 2) Vocab + Turtle. If most implementers and mapping writers want Turtle, they will go with the 2nd.

Eric explains options

seems that we can offer two options and resolve post-LC

Michael: can you render a proposal for this now

<Souri> +1 agree with Eric: breaking up a Rec into two Recs is not a big deal

Michael: sounds good to me
... can anyone create a proposal PLEASE

PROPOSAL: close ISSUE-57 with rendering the options in R2RML

<Souri> We have to decide: SHOULD ... Turtle vs. MUST ... Turtle

<Souri> as Ashok said

<Ashok> Mark Issue 57 in the document as requiring community feedback

<Ashok> ,]... and enumerate the options

<Ashok> s/.]//

[adjourned]

trackbot, end telecon

- DRAFT -

RDB2RDF Working Group Teleconference

16 Aug 2011

Attendees

Contents