Closed devowit closed 3 years ago
Here is the list of tags currently used: tags.zip
Relevance should be numeric, and the others should be strings.
User should be allowed to enter values outside the list.
first pass we're going to add dropdown menu's with autocomplete text fields for the options.
Ke-Thia is going to verify if Causx folks have an API that would return a list of available options, or any other preferred method of getting an updated list of tag options for validation.
The FactorClass
value should be prepended with http://ontology.causeex.com/ontology/odps/ICM#
to create an IRI.
See tag
array in sample variable metadata:
{
"name": "Employment in agriculture (% of total employment) (modeled ILO estimate)",
"variable_id": "employment_in_agriculture_of_total_employment_modeled_ilo_estimate",
"dataset_id": "WDI",
"description": "Employment in agriculture (% of total employment) (modeled ILO estimate) in WDI",
"corresponds_to_property": "PVARIABLE-QWDI-036",
"tag": [
"FactorClass:http://ontology.causeex.com/ontology/odps/ICM#EconomicAgriculturalCapability",
"Relevance:0.5",
"Normalizer:Standard",
"Units:% of Total Employment",
"DocID:897ace6541bb67924e7bd8f91633d144"
]
}
Here is the complete list of factor classes: FactorClass.zip
I foresee an issue with the url prefix in the gui because the tags are currently concatenated as strings of key:value
and there is a colon in the url -> http://ontology.causeex.com/ontology/odps/ICM#
Can we prefix the FactorClass
in the backend right before exporting the tags?
Or maybe redesign the endpoint to accept a json structure for key/value pairs?
I think the dropdown menu should not include the prefix. It should be added after the user makes the selection.
Tags are just strings. Having two colons in a string should not matter to the gui, right?
It actually makes it really difficult to deal with in terms of serialization. I need to come up with a way to systematically split the tags into keys and values using that colon, then concatenate them together before sending updates to the server.
Putting aside the possibility of users entering values with colons in it, sending that in to the backend then we get it back and need to figure it out all over again - guaranteed to break the flow at some point. String operations like that are notorious for being prone to errors. I would recommend doing serialization server side.
I am neutral on where the prefix gets added.
The way Datamart parses the string is everything before the first colon is the key, and everything after is the value.
some will have dropdowns, some will have numeric input, some will just be strings. @kyao needs to provide a document listing all of them