Solidarity Economy Schema - on Murmurations Protocol

This is the forum for Murmurations.network

Solidarity Economy Schema - on Murmurations Protocol

olisb

We had a good call with Colm and Dean from SEA today - and will be working together to see if we can take the schema (set of fields) they have already specified to map solidarity orgs in the UK (e.g. in Oxford) and build it out on the Murmurations Protocol. This would mean that Orgs that have entered data (via the SEA's initial Lime Survey) could then update their data via Murmurations.

The first step will be for SEA to share their Schema, and associated vocabularies / ontology/s so that we can ask any questions and start to build this out on Murmurations, as an SEA schema.

We're really looking forward to this - as our objectives are totally aligned with SEA 😉

doug

Sounds good 😀 It looks like users fill out a survey to get added to the map https://solidarityeconomyassociation.limequery.com/899558?lang=en which makes them yet another example of a map-directory fusion which would benefit from a murmurations-like system 👍️

dean

Hi guys,
This is the description of the schema (set of fields) we are currently using: https://github.com/SolidarityEconomyAssociation/open-data/blob/master/docs/SSE-Standard.md

The one comment I would like to make is that the ID field should probably be populated by Murmurations and would most-likely have to refer to a Murmurations identifier of the organisation.

If you have any questions, feel free to ask.

Looking forward to working with you! Any idea when you would be able to provide us data for the first map 😀 ?

olisb

Hi @dean Thanks for this 🙂
A few quick questions - which should probably be obvious but it's always good to make sure...

When you use codes for values - i.e. in the Legal Form list why do you need the code? i.e. why do we need to use "L2" to represent a Co-op? Why not just store the value "Co-op"?
Can I presume you never need / want to present the code value i.e. "L2" to a user...? So, if a Node Operator was making / updating their profile, for the "Legal Form" field you would want to present them with a drop down list of the options: Informal Group, Cooperative, Company, Non-Profit Organisation and Social Entreprise? (NB: "Social Entreprise." is spelt wrong on your Vocabs page) but return the associated L value in the JSON we present back to you?
Why do you show a dot after Definition? Especially if you don't want it to be included...
What do you expect / want to happen if someone wants additional options for a field - i.e. they would like to add charity which is a profit making entity?

I'm sure there will be other questions - but the answers to the above will help us get going...

the ID field should probably be populated by Murmurations and would most-likely have to refer to a Murmurations identifier of the organisation.

We use the URL as the unique ID - so would that be ok in the ID field (as well as the URL field)?

Any idea when you would be able to provide us data for the first map 😀 ?

Golly, now you're asking! I'm not sure... we have quite a bit of work to do first... but I would like to think it will happen before xmas...

dean

Hi @olisb no worries 😄

When you use codes for values - i.e. in the Legal Form list why do you need the code? i.e. why do we need to use "L2" to represent a Co-op? Why not just store the value "Co-op"?

You actually have to use "Co-op" instead of the code L2 (i.e. don't bother with the code, use the name directly)

Can I presume you never need / want to present the code value i.e. "L2" to a user...? So, if a Node Operator was making / updating their profile, for the "Legal Form" field you would want to present them with a drop down list of the options: Informal Group, Cooperative, Company, Non-Profit Organisation and Social Entreprise? (NB: "Social Entreprise." is spelt wrong on your Vocabs page) but return the associated L value in the JSON we present back to you?

Yes for the list, that would be brilliant, but it would need to show the the actual named values, e.g. Social Entreprise etc.. instead of the codes

"Social Entreprise." is spelt wrong on your Vocabs page"
thanks for the heads up!

Why do you show a dot after Definition? Especially if you don't want it to be included...

I think it was a historical error that became a standard when describing the vocab in html, we will patch it up 🙂

What do you expect / want to happen if someone wants additional options for a field - i.e. they would like to add charity which is a profit making entity?

At this point they would need to ask us to make that field for them. Our idea currently is to create a specified vocabulary that allows initiatives to describe themselves in a more uniform manner (rather than allowing them to describe themselves freely)

We use the URL as the unique ID - so would that be ok in the ID field (as well as the URL field)?

That seems sensible

Golly, now you're asking! I'm not sure... we have quite a bit of work to do first... but I would like to think it will happen before xmas...

OK, if you need support feel free to contact us!

Cheers

Colm

We could define the linked data URI for the murmerations data for
open.coop as lod.coop/murm/open/coop
or bristolpound.org as lod.coop/murm/bristolpound/org
?

olisb

Hi @Colm @dean et al...
I have been doing more thinking about your Solidarity Economy schema, and want to drill into some of your choices and the background thinking and explore how we might handle these fields on Murmartions. I'm hoping this will help us build your SEA schema - and tease out some of the issues / processes we will need to get right when designing our proposed 'Field Library' for use by other Schema Creators (SCs)... and the processes the Steering Group (SG) might need to follow when SCs propose new schemas and fields...

I'd like to take your Legal Form VES as an example.
To me this is a slightly odd field as it only contains 5 options:

Informal Group.
Cooperative.
Company.
Non-Profit Organisation.
Social Entreprise.

And if we are being accurate, not all of them are Legal Forms.

So, I'm interested to understand:

why you chose these 5 options?
if you absolutely require just those 5 options for your schema?
if you would be willing to use a 'standardized' field instead, with more options, for example a list of choices based on Wikipedia's list of legal entity types for the UK?

In order to make Murmurations work we need to encourage as much interoperability between fields as possible, and the SG needs to curate a list of the most practical fields in order for this to happen... Legal Form is a fairly standard field, which I think a lot of other Schema Creators will want to use, so I think it would make sense for the SG to create and curate this list as standard, based on the Wikipedia info / other source data, and for Legal Form to be standard field in the Fields Library.

But I'd be very interested to know what others think?

Colm

olisb You are right olisb. We inherited LegalForm VES. It is pretty poor and looks like it recieved minimal consideration.

It would be an excellent one to replace with something recommended by a Steering Group.

olisb

OK - this has given us lots more to think about... as has the rest of the SEA and RIPESS schema...
I think we are coming to the conclusion that if Murmurations is going to work then we need to find a way to enable Schema Creators to pick from a range of ways to use and manage fields:

(as @AdamM put in recently - in an ideal world Schema Creators would be able to)

just reference a library field, to use that field completely as-is from the library; or
reference the field and modify it or add more specific properties (length, required, etc); or
reference it but under a new name (to copy properties but remove interoperability), and optionally define additional properties; or
create a completely new custom field that doesn't exist in the library

We are working on ideas to enable this - or, if not the full list, as much of it as possible in the first instance...

I will post more in the Murmurations V1 thread.

This is the forum for Murmurations.network