Re: many to many tables in the direct mapping

On Wed, Nov 3, 2010 at 3:43 PM, Eric Prud'hommeaux <eric@w3.org> wrote:

> Cc:+= Michael Stonebraker <stonebraker@csail.mit.edu>
>
> * Richard Cyganiak <richard@cyganiak.de> [2010-11-02 12:39+0000]
> > 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's not some theoretical goal that motivates me; "monotonic" just
> happens to aptly describe the set of changes I can make to a
> relational structure and not have to revisit every piece of code which
> queries that structure.
>
> I chatted with Mike Stonebraker about this and he had similar
> reservations about having a different direct mapping for tables whose
> attributes happen to be covered by exactly two primary keys. While his
> concearns were more about complexity, he did offer the counter example
> for the many-to-many detection scheme: A marriage table may well have
> exactly two spouses in it, but it's not (in most places) a many-to-many
> situation. I think that the many-to-many-ness must be opt-in, and not
> in the direct/default mapping.
>
>
Exactly!! the many-to-many is optional!

Step 1: Create Literal Triples
Step 2: Create Reference Triples

Optional (the user will select if they want this option or not because the
user knows the schema)
Step 3: Create Triples from Many-to-Many relations

Even though it is optional, it should still be in the Default Mapping
document.

What do you think?


>
> > > 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
> > >
> >
>
> --
> -ericP
>