RDB2RDF - Formal mapping - semantics

21 Oct 2010

See also: IRC log


PatH, Marcelo, Alexandre, juansequeda, EricP, MacTed


<juansequeda> http://www.w3.org/2001/sw/rdb2rdf/wiki/All_Cases_for_Default_Mapping

<juansequeda> http://www.w3.org/2001/sw/rdb2rdf/directGraph/

@@: section 2

scribe: what happens with the PrimaryKey?
... @enumerates 7 cases that have to be treated@

ericP: the FK points to a CandidateKey in another table, but ti does not mean it's a PK
... or even that there is a PK

@@: is that the only case you need both tables?

ericP: yes

@@: let's write down any single case in specific sections

ericP: the recipe should tell you what it has to do
... the examples give you a sense of what it does
... if you don't want to have separate examples for each case, you can just say: "this example covers these cases"
... because some cannot exist on their own


ericP: let's be sure we agree on the examples

Marcelo: the use-cases are ok, the examples too
... it's just difficult to read
... I propose myself to re-organize for next week

ericP: what about terminology?
... tables VS relations
... SQL can give you multiple columns with the same name
... you cannot do it with SPARQL
... because @@
... so we have to decide what to do with headers and columns with the same name

juansequeda: can we vote to use SQL terminology instead of relational algebra terminology?
... choices are: relations/attributes OR tables/columns OR tables/attributes

<MacTed> tables/columns.

ericP: and we can speak about fnames instead of order

[ betehess: tables/columns ]

<MacTed> saying "relation = table" doesn't make sense to me. mixing tables/attributes makes even less.

<Marcelo> relations/attributes

@@: in relation algebra, people use "relation"

@@: in any of my classes, I apologize because the names are not fully defined

@@: I would suggest to use SQL terminology because of the audience

PatH: we at least need to define the terms very well

<MacTed> +1

<Marcelo> +1

Consensus around SQL terminology

ericP: +1

<juansequeda> +1 for using SQL terminology

<PatH> abstain. I go with the flow.

@@: SQL people use column, not attributes

@@: can we say: tables + columns + columns are unique within the table?

<MacTed> SQL identifiers == catalog.owner/schema.table.column

ericP: the schema has a unique mapping from to datatypes

<MacTed> column names are unique within table; table names are unique within owner/schema; owner/schema names are unique within catalog

ericP: tuple has unique mapping from names to value (or NULL)
... Marcelo and I propose a clearer version of the document
... expecting others will understand how genius we are :-)

<Marcelo> http://www.w3.org/2001/sw/rdb2rdf/directGraph/

ericP proposed a strategy for editing the documents

betehess: what is semantics?

ericP: you take an RDB and then you have an RDF graph
... it's all about the formalism of the formal mapping


given a SPARQL-to-SQL mapping to access SQL database, prove that the semantics of the translated SPARQL query executed against a particular RDB dataset is equivalent to the same SPARQL query executed against the same RDB dataset seen through the RDB2RDF mapping.


<PatH> +1 to whoever just spoke.

<PatH> Yes, we should do this. BUt this is about the semantics of the inputs and outputs of the mapping, not of the mapping language itself.

PatH, yes :-)

<Marcelo> +1 PatH

1. in the case of the Default Mapping, you have a function "mapping : RDB → RDF".

2. in the case of R2ML, you have a function "mapping : (RDB×R2ML) → RDF". The Default Mapping is just a particular case where you use the empty value as an inhabitant for R2ML.

<PatH> We could (not on IRC) draw this as a 'square' of functors which we want to commute.

<MacTed> +10000000 :-)

<PatH> BTW, I think this might be quite tricky to establish, I think. It *ought* to be easy, but details, details...

<PatH> Seems to me that there will be a big semantic mismatch arising from the 'open world' assumption (semantic: classical model thoery) of RDF. Have you guys discussed this?

<juansequeda> PatH, we haven't

<PatH> Oh.

<MacTed> PatH - not sure what issue you're seeing....

<MacTed> RDB ("schema first") is generally considered a 'closed world' model.

<MacTed> RDF ("schema last") is generally considered an 'open world' model.

<MacTed> 'closed world' fits fine within 'open world', which is what we're doing. RDB exposed as *part of* the RDF GGG.

<PatH> Yes, but if we try to establish semantic relationship using the semantics, we will find that RDF cannot express things that are implicit in the RDB semantic model.

<MacTed> example, please?

<PatH> Implied negatives for missing data, for example, which can be detected by SPARQL.

<PatH> Semantically, closed world is much stronger than open.

<PatH> stronger = fewer models, more implications.

<MacTed> can you state the problem you see more explicitly? I'm not seeing the issue you apparently are.

<PatH> Might take too long on IRC. Need a fully worked out example. Semantically, its that minimal models or algebraic semantics can express many things that cant be expressed in RDF wihtout negation.

<MacTed> so ... they can be expressed in RDF *with* negation, yes? or in RDF with "affirmative statement of negative"?

<PatH> Such things as: negative queries following from failure to find a match. And cardinality queries like 'how many'. None of this follows in the RDF semantics.

<PatH> But RDF doesnt have negation!

<MacTed> I think you're shifting from RDF to SPARQL, and from RDB to SQL

<MacTed> <a> hasNo <b> -- affirmative statement of negation :-)

<PatH> No, thats the problem. SPARQL can do things that arent supported by the RDF *semantics*.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/10/21 19:26:40 $

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/field/column/
Found Scribe: betehess
Inferring ScribeNick: betehess

WARNING: No "Topic:" lines found.

WARNING: No "Present: ... " found!
Possibly Present: MacTed Marcelo OpenLink_Software PatH betehess ericP juansequeda trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

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

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 21 Oct 2010
Guessing minutes URL: http://www.w3.org/2010/10/21-rdb2rdf-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

[End of scribe.perl diagnostic output]