Data model: Support string as alternative term for simple term, or vice versa

[danmichaelo]

Ok, here's a thing I completely forgot about when we sketched the DB schema. We don't currently support this, but the request for it has come up in discussions a few times.

Say we had the term Aerography (geography of Mars). Since we have a lot of strings on the form Geography : X, it would make sense to have a see reference from Geography : Mars to Aerography (or the other way around).

---

I'm leaning towards just including all the strings in the concepts table, with concept_type = "string". Of course, these will have no terms attached. When it comes to where the string component references should be stored, I'm in doubt. We could just add the

, topic         int             not null    references concepts(concept_id)
, subtopic      int                         references concepts(concept_id)
, form          int                         references concepts(concept_id)
, temporal      int                         references concepts(concept_id)
, geographic    int                         references concepts(concept_id)

stuff to the concepts table, leaving them as NULL for all non-strings. Or we could keep the strings table for that (perhaps rename to concept_components) and join it with the concepts table through the concept_id

[ewinge]

How about dropping strings entirely in the first version? :-)

[danmichaelo]

That's also an option ;) As long as we don't make it impossible (or very hard) to add support for them later on.

[bibliomari]

May one wish a walk through the data model someday soon?