Design (and document) a more flexible concept of "legislative references"

[guillett]

I would love to see

class aah_base_ressources(Variable):
    value_type = float
    label = u"Base ressources de l'allocation adulte handicapé"
    entity = Famille
    definition_period = MONTH
    reference = [
        u"[Article L821-3 du Code de la sécurité sociale](https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=C6BA89CEDDEBB102537424757CAA315C.tplgfr38s_1?idArticle=LEGIARTI000006744999&cidTexte=LEGITEXT000006073189&dateTexte=20180731)"
        u"[Article D821-9 du Code de la sécurité sociale](https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=C6BA89CEDDEBB102537424757CAA315C.tplgfr38s_1?cidTexte=LEGITEXT000006073189&idArticle=LEGIARTI000023097737&dateTexte=20180731&categorieLien=cid#LEGIARTI000023097737)"
    ]

transformed in Article L821-3 du Code de la sécurité sociale and Article D821-9 du Code de la sécurité sociale in the legislation explorer.

[MattiSG]

I am more in favour of slowly normalising reference fields over parsing Markdown, which opens room for much more complex, homegrown formatting.

[guillett]

🤔 managing markdown is probably too much for such a field.

@MattiSG what do you think about my strict proposal for normalising that field : [label](link) ?

[MattiSG]

Not too keen: that suggests Markdown while any other won't work, and needs setting a more complex regexp than necessary in place.

What I'm saying is I'd like to understand what people actually consider a valid reference. If it's always an URL with a title, maybe we'd be better served by downloading the title from the URL in the legislation explorer. Or conversely, if we always want to reference an article number, I'd rather have that formalised rather than free text.
See what NZ wants as well: https://github.com/ServiceInnovationLab/openfisca-aotearoa/wiki/Reference-types

I feel that [label](link) makes both too many and not enough assumptions: it says we suggest a reference is always a free-form label and a link, and I'm not quite sure this is what we really want.

[Morendil]

Agree that this as stated is something we'd better say "no" to, and even if implemented needs API support first; closing on this basis. Helping users find the actual legislation that the legislation explorer is supposed to help explore, that does sound like a good idea however. There were interesting discussions about ELI support within the context of the IPP parameter data.

[Morendil]

Reopening, with change in title to suggest addressing this as a UX/design issue rather than an intent to implement the originally requested feature. Cf. openfisca/openfisca-france#1252 among others.

[Br3nda]

I've been trying to find something that works for New Zealand. I've been thinking of making our own module for this that can read the api on the legislation website. I'm not sure how that would work yet. We've already got more info to store than we can currently put on tbe python classes in openfisca. Eg a reference in more than one language, or a reference for different periods of time.

[Morendil]

Thanks for your input @Br3nda !

[Morendil]

@Br3nda Have you looked into ELI or Lex? Are you aware of similar microformat initiatives elsewhere?

I'm feeling mounting pressure (in part thanks to @guillett) to find a better way to deal with this than we are at present. It's tempting to make "reference" a type-tagged object, i.e. slap a "type" field on it, which could be "markdown", "ELI", "Lex", "free text" or "URL" for instance, and allow the "content" field to be whatever the type dictates. Your own ontology tags could have a type of their own too (that would probably be better than "free text").