Dialog bugs

[ColmMassey]

• [x] The facebook link seems to be constructed incorrectly. E.g. Covid-19 Community Response - Prestatyn
• [x] The dialog displays each inititative as a Co-operative - This is not correct. It may be a data rather than dialog issue. If is is data, stop labeling the initiatives as co-ops on processing. Create a ticket to create an approriate Mutual Aid qualifier in ESSGlobal (ticket https://github.com/SolidarityEconomyAssociation/open-data/issues/52)

[wu-lee]

The link for an initiative I checked is https://www.facebook.com/https://www.facebook.com/groups/220944599058149/?ref=share

That is clearly malformed - this link works: https://www.facebook.com/groups/220944599058149/?ref=share

The URL in the data is not malformed, so it is a dialog issue.

[wu-lee]

Create a ticket to create an approriate Mutual Aid qualifier in ESSGlobal

Is this meant to be conditional on it being a data problem? If not can you explain this a bit more?

[ColmMassey]

Create a ticket to create an approriate Mutual Aid qualifier in ESSGlobal

Is this meant to be conditional on it being a data problem? If not can you explain this a bit more?

The sausage factory has defined them all as co-ops. This is not correct. So we need to stop that.

Seperately it would be good to have a Mutual Aid qualifier for initiatives, which would requiresome thinking.Looks like I've already created a ticket to cover this. https://github.com/SolidarityEconomyAssociation/open-data/issues/52

[wu-lee]

Regarding the Facebook links. What seems to happen is:

• the original CSV data generally contains full Facebook URLs (looking at oxford/newbridge/mersey/deep-adaptation, mutual-aid, ica; the others don't seem to include facebook links at all)
• oxford etc. (limesurvey core) conversion removes the http://facebook.com part, keeping the path alone
• sea-map expects this, and sticks it back on again - so the links work in these cases
• mutual aid's converter does not strip the domain, so it doesn't work - the URL gets mangled

But in addition to the problem above, it seems like the original mutual-aid data has non-facebook links in the facebook fields (e.g. Hooshmand World Peace Foundation has http://www.globalpeacehouse.com/, and there seem to be plenty of others). So it's not as simple as just stripping the facebook domain off the link, as it is for limesurvey data.

We could:

• tell mutual-aid-wiki maintainers they need to validate this field to ensure it is a facebook URL
• validate this field ourselves drop any that fail to start with the facebook domain
• do nothing, and let these fields link anywhere

In cases one and two we could then strip the https://*.facebook.com domain part from the URLs and let everything work as-is, resolving the broken Facebook link problem. In case two, this might lose information in the process.

Case three has some appeal, but we can't simply let these be free links because they aren't in the other data sets (like oxford). To do this we would also need to adjust the limesurvey conversion in the process: effectively it's a change in our standard CSV schema, which implicitly expects facebook field to have facebook paths rather than full URLs in them.

(This expectation would be better made explicit, IMO, which is what I hope the standard schema will do eventually - include validation rules on the contents of fields, so we can spot these problems earlier rather than later.)

Any thoughts on this @ColmMassey ?

[ColmMassey]

See https://github.com/SolidarityEconomyAssociation/open-data/issues/35

[wu-lee]

Just to clarify, I think the second item (about the organisational strucutre of Mutual-Aid), must have been ticked because there's a ticket for that. (https://github.com/SolidarityEconomyAssociation/open-data/issues/52)

To expand on what's going on: it's a data issue. The converter currently hard-wires it to "Co-operative".

We can hard-wire it to a new qualifier term, but this requires referencing a newer version of ESSGLOBAL than V2a, and we currently can't do that and have the dataset rebuilt automatically. See https://github.com/SolidarityEconomyAssociation/covid-mutual-aid-project/issues/2#issuecomment-810384568 - the reason is that we can't currently mix and match schema versions for different open-data sets on a given sausage-machine build server, and the two we have are on V2a. So I think that needs to be addressed in order to be able to use a new qualifier.

[ColmMassey]

For the moment, let's just drop creating the triple which calls this a co-op

essglobal:organisationalStructure https://w3id.solidarityeconomy.coop/essglobal/V2a/standard/organisational-structure/OS115 .

We can add the Mutual Aid qualifier when we are ready to next upgrade ESSGlobal again.

[wu-lee]

Ok. I discovered this is effectively what happens if I change the conversion script to write "Mutual-Aid" instead of "Co-operative": it doesn't match any term label, and there is no triple created. This then fouls up the SPARQL query which mandates an organisational structure field - however making that optional is a trival change. I'm not sure what then happens in the dialog if this field is absent, will have to check.

[edit] It isn't great that this happens silently - I think the conversion should fail, or at least warn, if there are invalid values.

[wu-lee]

Fixed on dev-0 I think.

• Website URL clean-up beefed-up. Facebook URLs benefit from this, plus some Facebook-specific validation. If the Facebook link fails validation, the website URLs are searched for one which does (there often is).
• Organisation type is omitted entirely.

Just as an aside: the data seems to be very poor quality. Website and Facebook URLs are all over the place, including broken ones, What's App links, phone numbers, URL shortners to who-knows where, links to non-existant sites, links to irrelevant sites, and text written for human consumption.

[ColmMassey]

This can be pushed to prod now.

[wu-lee]

Done - sausage-factory build also prodded to rebuild the production data, with cleaned-up facebook links.