Forbid reference column pointing to unexpected table?

[Anaphory]

In looking at the new get_foreign_key_target Method in pycldf, I noticed that it makes sense to always return and heed the referenced table of a foreign key – but that also suggests that a formReference might have a foreign key pointing to a table that is not a FormTable. What would that mean?

I think that the CLDF specs should specify that an xxxReference column SHOULD be a foreign key to the XxxTable, and that doing it differently MAY lead to undefined behaviour in software. CLDF software SHOULD use the referenced table and check it for the columns needed.

For example, my code that looks for the segments of a form referenced in a CognateTable will look for

dataset[dataset.get_foreign_key_target("CognateTable", "formReference")[0], "segments"]

instead of

dataset["FormTable", "segments"]

If that fails with a KeyError, it would be allowed to add a segments column to the FormTable, though, and expect everything to be fine, because my segmenter functionality can't be expected to work on weird arbitrary tables.

[Anaphory]

All these reference properties already have an entry <dc:references rdf:resource="#LanguageTable"/> or equivalent, and the comments read something like

An identifier referencing a language either

• by providing a foreign key into the LanguageTable or
• by using a known encoding scheme.

Can – and should – we formalize this “or” somehow in the specs?

I guess we still want the potential flexibility of people coming up with alternative encoding schemes for such references in the future, so I would understand it if we do not formalize it yet, or not yet for all properties.

[xrotwang]

We might want to spell out more clearly, that the or means, the reference must be a foreign key (or NULL) if a LanguageTable exists.