<Ashok> scribenick: hhalpin

<Ashok> scribe: Harry

<Ashok> PROPOSAL: Accept the minutes of last meeting, see > http://www.w3.org/2010/08/03-rdb2rdf-minutes.html >

Ashok: The plan of the meeting will be for Souri to finish the proposal, and then address comments.

<Souri> comments on Richard's comments: http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2010Aug/0013.html

Ashok: I think we have a reasonable agreement on the SQL-based approach, so we should see the next steps

Souri: Would prefer to go over the comments in detail first.

cygri: that's fine

Comments on SQL-based approach

cygri: I have a number of nonfunctional improvements
... and then some expressivity requirements
... then some things for author convenience
... 1.1 don't include URI in pointed brackets
... souri seems to agree

1.2 a renaming away from property URI to instance URI map

<juansequeda> +1 for InstanceURIMap

cygri: I would prefer it to be called URI instance map

souri: I agree

cygri: 1.3 URI graph name

souri: let me explain, for each column, the graph URI property name is one way of identifying the graph with the column.
... we could avoid it as in previous treatment
... but richard points out you could have more property maps that generate the same names
... so we should need to keep the graph name
... for each property name we should have a backpointer that explains which graph URI name it goes with
... but once you have that, you really a name for the graph property

cygri: it appears that I may have been confused
... I thought it referred to a RDF property
... but this may not have been your attention
... but what you just explained, that a property mapping has a mapping to a graph URI mapping
... then that's a design that I would be happy with.

juan: Could you give us an example?

<Souri> http://www.w3.org/2001/sw/rdb2rdf/wiki/Revised_Example_of_SQL-Query_based_Approach

juan: so the semantics of that are specified inside the URI?

Souri: It doesn't access the URI, it's just the name of the graph
... so the syntax of the URI is not at all important.

cygri: my comment is that we can easily duplicate information
... using keymaps

ericP: I'm projecting out 2 or 3 tables
... if a particular column in one of the tables
... and that acts as a key
... in the regular database

souri: it's a very simple approach, in fact, we've already simplified it in our prototype
... so we identify a foreign key
... and then the key sequence also references this primary key
... now, foreign key can be any expression
... so in general, all we need to know that these columns are available
... that are used in some expression (x+y+2)
... but I realized we do not need the whole key definition
... all we really need
... is the name of the foreign key
... an object property name
... so we need to translate that.
... all we really need is the corresponding join condition
... we need the corresponding consequent.
... we need a template.
... but if it's a five column key, then we have five conditions, and so all we need from the mapping specifier is that template.
... which gives us a join condition for the foreign key
... which allows us to work through the aliases

ericP: So there are a class of functions that are reversible, but for those that aren't we have to materialize them

souri: that's not the issue
... imagine if x is exposed as f(x), but only x is exposed, but if the foreign key is f(x)=d(y), where d may not be reversible, but all we need is the info that f(x)=d(y) as that needs to be put in join condition

<ericP> Souri has convinced me that reversibility is not required for creating a join constraint; the engine will be evaluating this on specific tuples

cygri: I will study this more
... Second set of points
... we need to have blank nodes as subjects

<ericP> (of course, non-reversibility leads to table scans, but that's not our problem)

cygri: different literals genreated from same property name could have different langauge tags

souri: I agree, good point
... the question is can we have it in the expression that generate the literal value that give it a language tag

<Souri> title || "@en-us"

cygri: my preference would be to keep it separate

souri: not sure if I agree

cygri: we don't have this in d2rq
... but no-one has ever asked for it.

ericP: For example, SPARQL 1.1 doesnt include dates but does handle datetimes

cygri: So it would be nice if typed literals could be contracted and specify an override for a datatype

<ericP> "2010-08-10"@date => "2010-08-10"^^xsd:dateTime

souri: but for computed data types how do we handle this?

cygri: we do need some kind of casting
... numbers in string columns

souri: I now agree with the importance, but not sure how to handle computed types, that's all.

ericP: we do not necessarily need to validate the types

cygri: flag this as open issue?
... Entity value schema
... here are the attributes that the column actually represents
... we would want to map this attribute to different properties
... you seem to think this approach is OK.
... I remember
... there was a long e-mail from Orri from OpenLink that having computed property URIs is not a good idea.
... 2.5
... we might have a column with an extended data in another table
... we want numbers that identify the particular extent that specify the particular some readable text
... so having a lookup table is a good idea

souri: not sure if this is a good idea
... as imagine if the lookup table gets too big
... this may have impacts on the computation

cygri: we implemented it in d2rq
... and it worked in a straightforward manner

souri: I will update the wiki

Ashok: let's leave the rest for next week

cygri: he agreed with most of the rest of these.

Ashok: is this a reasonable direction?
... are we headed towards a first public draft document?

sequada: Looks great, but we need to work on semantics

Ashok: No strong negatives

<LeeF> I'm wondering if we're going to talk about syntax before FPWD

<LeeF> because I think that's very important

cygri: I'm happy with expressivity and general design
... some question about syntax

Ashok: let's talk about syntax last

juan: datatypes and generating URIs
... myself and Marcelo are working on a semantics document

Meeting Adjourned

trackbot, end meeting

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/??/Orri from OpenLink/
Succeeded: s/extent/some readable text/
Succeeded: s/hospitality/data in another table/
Found ScribeNick: hhalpin
Found Scribe: Harry
Default Present: Souri, soeren, juansequeda, cygri, Ashok_Malhotra, MacTed, hhalpin, LeeF, EricP, Souri_Das
Present: Ashok Richard EricP Harry Ivan Juan LeeF Ted Soeren Souri
Regrets: Boris Marcelo
Got date from IRC log name: 10 Aug 2010
Guessing minutes URL: http://www.w3.org/2010/08/10-rdb2rdf-minutes.html
People with action items: