22 Feb 2011

See also: IRC log


Ashok, Alexandre, Boris, David, Ted._Soeren, Souri
Seema, Richard



<scribe> scribe: bertails

<scribe> scribenick: betehess

approving minutes from last telcon

PROPOSAL: approving the mminutes


<soeren> +1

RESOLUTION: minutes are approved

<ericP> ivan and i will be there in a moment

Ashok: juansequeda you requested to speak about @something@
... I'd like you to speak about the DM spec
... then we can speak about '#' and '=' stuff
... last time we spoke about publishing the spec
... the DM guys were a bit hesitant
... as they prefer to publish when they think they are ready

juansequeda: we said to publish in *two* weeks
... that was my issue

Souri: I'll be on vacation in one month

juansequeda: I'll leave for Chile on Friday
... we'll work with Marcelo
... I'd like to speak the many-to-many with richard

<Zakim> MacTed, you wanted to discuss provenance

MacTed: that may be dangerous thing
... I haven't had time to write that earlier
... wanted to speak about that several weeks ago
... about temporality issue
... ericP was operating under the assumption that things are static forever
... and other people too
... so there has to be a provenance associated with everything
... "this stuff is right at that moment"

Ashok: your recommendations?
... you want the mapping having a timestamp?

MacTed: not necessaraly
... if we use a named graph, it will be easier to describe this kind of things
... we have to shift the RDF world to recognition of time nature of data

Ashok: MacTed you have an action on blank node generation

MacTed: it's associated with that
... blank node should be discouraged when possible
... i'll do my best to address that next week

Souri: you're speaking about versioning
... DM does not specify anything
... we look at the schema only when you processed the query

<ericP> +1

Souri: so the DM should not reflect that

<ericP> (to souri)

MacTed: speaking about SPARQL-to-SQL?

Souri: yes

MacTed: it's not related
... speaking about RDB to RDF

Souri: it's materialisation?

MacTed: it's part of what I'm saying

<ericP> i don't see how whether instance data has bnodes or URIs in some places impacts the schema mapping

<Zakim> betehess, you wanted to ask when we publish

ericP: if we're not doing materiazation
... I don't see in any how being BN or not impact a schema mapping

Ashok: I agree that for me there are different things

<ericP> perhaps a write-up is in order

MacTed: why would you use a BN?
... only because it's true at this instant

[MacTed arguing]

<ericP> "baseless"?

MacTed: your postulate that your PK will refer forever this tuple is not true

Ashok: hold on, there are quite different things
... we can keep arguing about that but how is that tied up with the temporal thing?
... the BN stuff happens just because we don't have a PK


<ericP> the logic remains consistent either way

<ericP> the question of bnodes is an engineering issue

<ivan> I can witness the validity of Alexandre's statement:-)

<MacTed> DESCRIBE <bnode>

<MacTed> danger.

<ericP> with bnodes or IRIs for subjects of tables with no primary key

<juansequeda> +q

ivan: if not BN, the current mapping can easily generate a URI
... if it's not BN, how would you generate a URI saying it's coming from uncertain knowledge

MacTed: even something as "NULL" and a number

<ericP> germain test case: http://www.w3.org/2001/sw/rdb2rdf/wiki/R2RML_Test_Cases_v1#2duplicates0nulls

MacTed: means something now, not later

<ivan> http://example.org/{UUID}

<ericP> how do we address the two entries which are identical in the DB?

Ashok: but the idea was to distinguish between nodes, right?

ivan: using UUID, you have the unicity
... that's engineering

<Souri> As I explained in my earlier email http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Feb/0035.html, I think either bNode or (non-reusable) IRI would work fine.

ivan: it just that it won't be dereferencable
... some people will be unhappy about that

MacTed: if it's not dereferencable it's a BN
... and there's no point

<Zakim> ericP, you wanted to ask how we would differentiate the two rows in http://www.w3.org/2001/sw/rdb2rdf/wiki/R2RML_Test_Cases_v1#2duplicates0nulls

ericP: I'd to address the test case I pasted
... re: identical rows in a table
... MacTed please address that, that will help a lot

<Souri> The email I had sent earlier was based on the assumption that we do not materialize (at least) the instance triples.

MacTed: sample answer is: it's bad data and bad scheme

ericP: well, in earlier 80s databases implementation died because of not addressing that

MacTed: this is something you cannot do well
... there *is* a database id

ericP: if we're doing sparql to sql, you don't have access to that knowledge
... it's everybody's objective

<ivan> +1 to betehess

<Souri> +1 to ericP re: we are not standardizing SPARQL-to-SQL translation, but we are keeping that in mind

<Souri> and Ashok

ivan: I understand Alex's remark
... but to be fair, I can still use BN in SPARQL
... we already do that

ok, but in that case, MacTed will have to redefine graph equality through SPARQL + Blank Node :-)

MacTed: if it has a name, it is not a BN

Ashok: we have to create URIs to distinguish different rows
... it would be useful if you could write something so we can speak about it next week

MacTed: I'll do my best

Ashok: anyway my understanding that this "provenance" is a different question
... next item was many-to-many
... byt juansequeda wanted to wait for richard

juansequeda: can speak about it

many to many

[juan describes again]

Ashok: should we recognize that as a special case?

juansequeda: last time we decided to KISS
... I propsoed a switch but people were reluctant
... richard said that with d2rq, people were already asking about that

<Souri> Is there an issue and/or action item on it?

<ericP> +1 to simple

betehess: KISS

Ashok: so we don't do anything special, right?

ericP: basically yes

<juansequeda> KISS = Keep It Simple Stupid

ericP: if you detect many-to-many, indeed it works, but that's modeling

Ashok: it can be wrong too

ericP: stonebreaker@@ proposed an example where you got it wrong

MacTed: just as ericP said, you can do wrong
... so it should not be part of the DM
... can be handle later

Ashok: looks like we have a direction on this
... but we have to wait for richard
... let's see that next week with him

juansequeda: and MacTed can propose something

<boris> betehess is trying to say sth

# vs /

<Ashok> http://www.w3.org/2001/sw/rdb2rdf/track/issues/10

<juansequeda> ISSUE-10?

<trackbot> ISSUE-10 -- Hash vs Slash -- open

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

ericP: what is the right way to describe an identifier
... one implies a 303
... it's an issue for database folks
... cause they have big data

<Ashok> the option is to use a fragment identifier

ericP: so if you go into an extra GET
... but the payload can be huge
... for no real value
... that's the argument for #
... the argument for / is that it's a better model
... it's easier for local names too
... will write the example down

Ashok: the fragment id semantics is in the media-type

<juansequeda> What are the two possibilities? http://foo.example/DB/People/ID=7#_ vs ??

ivan: if I have a # uri, I expect the whole before the # to come into the client
... I don't know what it means if this is coming from a database
... the client is not require to send what is refered behind the #

<Ashok> to the server

ivan: afaiu, everything has to be dereferencable, I don't know what it means in this case

Ashok: if you're going this direction, you're requiring JS running on the client
... not ideal

ivan: yeah

<ericP> juansequeda, i think http://foo.example/DB/People/ID=7#_ vs http://foo.example/DB/People/ID=7

juansequeda: wanted to make clear
... ok, ericP answered :-)

<Zakim> ericP, you wanted to answer implicit cloud-size question and to

juansequeda: if I do a prefix...
... with the #, I cannot do that

ericP: if we paste an identifier, we don't want to get the whole database
... we want to identify this or that

<Ashok> ... or whole table

<juansequeda> PREFIX ex <http://foo.example/DB/People/>

<juansequeda> ex:ID=7 vs ex:ID=7#_

ericP: you can use PREFIX to refer to sub parts

juansequeda: I can't write this PREFIX with # :'(

<MacTed> http://foo.example/DB/People/7#_ vs http://foo.example/DB/People/7

<MacTed> can't have equals, so don't spec it to *have* equals

Ashok: someone has to tackle it

<boris> we have to document all of this discussions

<boris> these

<Souri> I am at risk for next week's meeting

<ericP> local names for rdf/xml: http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName

<ericP> local names for SPARQL: http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/#rPN_LOCAL

<ericP> +1

<MacTed> thanks, ericP - that'll be helpful

Ashok: let's just Alexandre work on the document
... we'll speak formally about that later


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/02/22 18:04:58 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/@@/blank node generation/
Succeeded: s/don't to/want to/
Found Scribe: bertails
Found ScribeNick: betehess
Present: Ashok Alexandre Boris David Ted._Soeren Souri
Regrets: Seema Richard

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 22 Feb 2011
Guessing minutes URL: http://www.w3.org/2011/02/22-rdb2rdf-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]