Re: many to many tables in the direct mapping

Eric,

On 2 Nov 2010, at 08:56, Eric Prud'hommeaux wrote:
>  The monotonic addition of columns to the database results in
>  non-monotonic changes to the direct graph, breaking existing queries
>  and mapping rules.

I don't find this reason compelling.

Changes to the source database break queries and mapping rules. That  
is sort of obvious. It will not come as a surprise to users either --  
changing your database messes up your SQL queries and views too.

Removing or renaming a column will break things no matter what. Same  
for adding or modifying primary or foreign keys. If adding a column to  
a many-to-many table breaks queries or mapping rules too, then so  
what? I don't see what's so special about that operation.

As a matter of principle, I think this WG should not inconvenience a  
large number of users (everyone who has many-to-many joins in their  
schema) in order to maintain some notion of theoretical purity  
(monotonicity).

>  It will be harder for folks to write papers and innovate soundly
>  with a more complex model.

The interests of users should outweigh the interests of folks who  
write papers too.

Best,
Richard




>
> ¹ http://www.w3.org/2001/sw/rdb2rdf/directGraph/alt#id0xa4a2a060
> ² http://www.w3.org/2001/sw/rdb2rdf/directGraph/#rules
>
> For example, consider a PersonAddress table which connects a Person to
> an Address:
>
> ┌┤Person├────┐   
> ┌┤Address├───────┐   
> ┌┤PersonAddress├───┐
> │ ID │ fname │ │ ID │ city      │  │ person │ address  
> │
> │  7 │ Bob   │ │ 18 │ Cambridge │  │      7 │      18  
> │
> │  8 │ Sue   │ │ 19 │ Austin    │  │      7 │      19  
> │
> └────┴───────┘  
> └────┴───────────┘  │      8  
> │      19 │
>         └────────┴─────────┘
> We can generate a direct graph for PersonAddress
> @base <http://db.example/ContactDB/> .
>
> <PersonAddress/person.7_address.18#_>
>    <PersonAddress#person> <Person/ID.7#_> ;
>    <PersonAddress#address> <Address/ID.18#_> .
> <PersonAddress/person.7_address.19#_>
>    <PersonAddress#person> <Person/ID.7#_> ;
>    <PersonAddress#address> <Address/ID.19#_> .
> <PersonAddress/person.8_address.19#_>
>    <PersonAddress#person> <Person/ID.8#_> ;
>    <PersonAddress#address> <Address/ID.19#_> .
>
> OR, as I believe you propose, we can generate repeated properties:
>
> <Person/ID.7#_>
>    <PersonAddress/person_address> <Address/ID.18#_> ;
>    <PersonAddress/person_address> <Address/ID.19#_> .
> <Person/ID.8#_>
>    <PersonAddress/person_address> <Address/ID.19#_> .
>
> This one is attractively more terse, but, the addition of a column to
> the database:
>                                     
> ┌┤PersonAddress├───┬─────────┐
>         │ person │ address │ primary │
>         │      7 │      18 │ true    │
>         │      7 │      19 │ false   │
>         │      8 │      19 │ true    │
>          
> └ 
> ─ 
> ─ 
> ─ 
> ─ 
> ─ 
> ─ 
> ──┴─────────┴─────────┘
>
> *retracts* those repeated properties and generates instead a direct
> graph for PersonAddress with the three additional primary predicates:
>
> <PersonAddress/person.7_address.18#_>
>    <PersonAddress#person> <Person/ID.7#_> ;
>    <PersonAddress#address> <Address/ID.18#_> ;
>    <PersonAddress#primary> "true"^^xsd:boolean .
> # + 7_19 and 8_19
>
> These retractions break queries and change the interface graph even
> though the addition of the column does not change the interpretaion
> of any of the other columns in the database.
> -- 
> -ericP
>

Received on Tuesday, 2 November 2010 12:39:48 UTC