This is related to the namespace discussion in #17

@CharlesNepote 's example use of namespace was:

"recalled_product" => "yes"
"recalled_product:date" => "2021-05"
"recalled_product:link" => "https://rappel.conso.gouv.fr/fiche-rappel/383/Interne"

For the property above, the namespace suffix is also an indication of the type of value for the property.

I'm thinking it would make a lot of sense to specify the type directly in the key:

recalled_product.boolean = true | false -> the UI can handle displaying and inputing in different languages
recalled_product.date : the UI knows it's a date, so it can display a calendar
recalled_product.link : the UI knows it's a link, so it can display it as a link

Other useful types:

some_property.string
some_property.string:fr -> French value for the string (as suggested by Charles in #17)
number_of_units.integer

We could try to indicate "dimensions" as well:

packaging:width.length + packaging:height.length + packaging:length.length : all 3 properties are of the "length" dimension.
price_on_packaging.price : the propert is a price

And something that would be immensely useful is to allow taxonomies in types:

packaging:main_color.taxonomy:colors : the UI would allow input and output of "Blue" in any language

Something else that would be very tempting is to indicate in the property key name if it can have multiple values or not.
e.g. "packaging:colors.taxonomy:colors@" -> the @ (or any other sign or scheme) indicates that the property can have multiple values.

Of course all this should be transparent to users, they won't have to deal with the : , the . or the @, the UI will take care of it.

What do you think?

Part of

• 🎯 What can I work on ? (Folksonomy Engine) #70